ID Site implementation

Synopsis:

* New method `Application.createIdSiteUrl()` for creating the redirect URL that takes the user to the ID site

* New method `Application.handleIdSiteCallback()` for reading the JWT response from the ID site callback and building an `AuthenticationResult`

* New property `idSiteResponse` on `AuthenticationResult` for storing the decoded JWT response value - this is where you can get your `state` property from if you specified it.

* Implement a default Nonce Store by using a region in the data store cache

* New option `nonceStore` on the Client constructor, accepts an interface object for interacting with a custom Nonce Store
Why have a `getAccount()` method when, using an object literal, `result.account` would return the same thing?  To me there is a very clear delineation of when an object vs a class instance should be used: if logic needs to happen other than getting/setting of any sort, a class instance with methods (logic) make sense.  If this doesn't need to happen, a simple JS object makes sense (to me).

Regarding `isNewSub`, we definitely should not bubble up implementation details to SDK users: we might change our token approach in the future, or modify it, and we need that buffer to ensure that we won't break code that uses the SDK.  Internal implementation details should _always_ be decoupled from end-user code.

And because the result represents more than AuthenticationResults - it's a result for any ID Site operation - we shouldn't 'overload' the AuthenticationResult implementation.  I see 2 problems with this:

1) It implicitly treats the operation as an authentication operation, and SDK users will be likely to think of it this way moving forward.  This is definitely not desirable - the ID Site stuff is a wealth of functionality and we can't pigeonhole/relegate it to be thought of as mostly useful only for authentication, and

2) To me, the current approach feels like we're trying to 'shoehorn' something for our own (the SDK implementation team's) convenience, rather than Doing The Right Thing (tm) to ensure that our SDK end-users code to a specifically designed API.

These reasons are why the Java SDK does not use the existing `AuthenticationResult` type for these operations, and a new type was created.