Added Principal to OAuthToken

[lbredeso]

This is a simple shortcut to prevent applications from needing to know what piece of additionalInformation should be considered the Principal. This mirrors functionality in dropwizard-oauth.

[llinder]

Feels a little odd that peculiarities of our token handling is ending up in OSS libraries. Other than that 👍

[jeff-blaisdell]

I'm a bit with Lance. Also, even in our own mixed up world the user_name isn't technically our principal is it?

[lbredeso]

@jeff-blaisdell I was going off of this, and it's totally possible I'm misunderstanding: https://github.com/SmartThingsOSS/dropwizard-common/blob/master/dropwizard-oauth/src/main/java/smartthings/dw/oauth/OAuthToken.java#L35

[lbredeso]

@jeff-blaisdell I think it's actually "principal" in additionalInformation.

[lbredeso]

I pushed a change that I believe is more correct. We already have ST-specific stuff here and in dropwizard-oauth, but I guess it's unclear to me where to draw the line. If folks think this doesn't belong in this repo, no big deal, just let me know, and I can close this PR and compute it myself elsewhere, was really just trying to align w/ dropwizard-oauth, which I now realize isn't correct either.

[jeff-blaisdell]

I believe the original intent was to somewhat mimic this Spring class:
http://docs.spring.io/spring-security/oauth/apidocs/org/springframework/security/oauth2/common/DefaultOAuth2AccessToken.html

Which we haven't strayed too far from. Our concepts of principal I think are a bit unique.

Another option would be to provide a mechanism for overriding the DefaultOAuthToken impl with our own custom OAuthToken impl in our private auth library.

I defer to @llinder on this one.

[lbredeso]

I think I found a place in an internal library to do this parsing that I think is better than this. I'm going to close this PR.