Add globus_sdk.IdentityMap for Auth ID lookups

[sirosen]

The IdentityMap is mostly a port of the LazyIdentityMap found within the Globus CLI. It has several notable differences, however:

• it accepts usernames or identity IDs and internally differentiates them
• it is lazier than the LazyIdentityMap because it only looks up one batch at a time (maybe the CLI implementation should have been called EagerIdentityMap)
• it has an external interface more clearly defined for consumers to interact with it (because that's the point of doing this work, basically)
• it will "prioritize" a given key by forcing it into a record batch for lookup
• it returns full record dicts, not just usernames

In addition to the IdentityMap itself, this includes tests which exercise almost all of the IdentityMap behaviors.
The IdentityMap is primarily a wrapper over an internal _cache dictionary which maps both usernames and IDs, undifferentiated, to records. You can del items from the cache to force fresh lookups if you believe data has gone stale, and IdentityMap.get has the same signature as dict.get.

It's important to note that IdentityMap does not implement the full Mapping protocol (defined in modern pythons by the collections.abc module). The issue for us in this case is that certain operations like __contains__ are very unclear. For example, if the map has a key added to it but it hasn't looked it up yet, does it "contain" that key? If you were checking to see if a key had already been added the
answer is "yes". But if you wanted to know if idmap[key] will KeyError, the answer is "maybe/unknown". The only way to answer "contains" if you want to know that is to actually do a lookup, and having in checks side-effecting in python seems bad.

Therefore, in is intentionally left undefined. We can add new methods, similar to has_key(key, resolved/unresolved=True/False) in the future if users come to us with a desire for this information and can clarify their use-cases.
For the most part, idmap.get(key) is not None should suffice if anyone ever cares to check.

I worked through tests mostly with the goal of complete line coverage, but there are some untested behaviors I can target if it seems important.

Absent a more obvious place to put this in docs, I've included it on the Auth clients page (similar to the TransferData and DeleteData objects).

Resolves #366

[sirosen]

I've done some cleanup per review, and also because I realized that I had used httpretty in a slightly confusing way.

I also went ahead and implemented the "pass a custom cache" variant, but kept it in a separate branch ( sirosen@bbf7983 ). We can pull it in, or just discard. (Or, if you strongly disagree and want a default shared cache, we can discuss further, of course.)