Consider including region in callback data

# API

Should be relatively easy to add to the API, providing an object instead of a string, like so:

``` json
{
"name": "aws",
"region": "us-east-1"
}
```

And possibly just use the default `"unknown"` if it can't be determined.

This would, of course, represent a major/breaking change. Unless the API was changed in a backwards-compatible way by accepting an optional `opts` object that could ask for region data via `region: true` or `detailed: true`. But this might be overkill.
# CLI

This poses a couple interesting problems for the CLI:
##### Does the CLI return the extra info by default, or should it be explicitly requested (and how)?

If it's included by default in the API, I would argue it should be included by default in the CLI. However, it would certainly be acceptable to make it opt-in via a flag like `--detailed` or `--verbose`. (It could also be opt-out via `--brief` or `--simple`.)
##### How should the data be represented/formatted?

I think, by default, we should stick with a simple format that is human-friendly but also not too difficult to parse, perhaps `name:region`. Otherwise, it would be nice to support explicit CLI options to output more machine-friendly formats, like `--json`.

All of the above is open to suggestions. What do you think?

The issue names the API and CLI but no files or tests. Start by locating the current callback data and CLI output paths, then resolve the proposed region representation, defaults, and compatibility questions. Done means the API and CLI behavior, including any opt-in or output-format choice, is explicitly decided and implemented.

Written by the indexing model from the issue text.