SDK: Refresh Token implementation

[langleyd]

Supports changes in element-hq/element-ios#5293 to resolve element-hq/element-ios#5292

Included in this PR

• Introduces a new SDK option MXSDKOptions.authEnableRefreshTokens to enable refresh tokens. Access token auth will remain in place for the user while logged. Refresh token auth will be used on next login/register.
• Implemented the login/register, refresh endpoints as detailed in Implement Refresh Tokens element-hq/element-ios#5292.
• The refresh token are now stored on MXCredential, it has a function for updating the tokens when they are refreshed. It is the source of truth for these values.
• Previously the access token was long-lived, was passed around and multiple references to it were held without ill-effect. Now that access tokens are short-lived, the approach is to have MXCredential be the source of truth and other classes that require it such as MXHTTPClient to pull in the value on demand.
• MXHTTPClient requestWithMethod functions in the past forked, with half of the function signatures supporting an auth mechanism for the Identity server and the others being for homeserver requests. Rather than maintaining two different auth mechanisms for the http client there I created one that servers both identity and homeserver auth. It comes at the risk of updating the identity server auth but with the benefit of approach/code actually being understandable(vs having two implementations).
• MXHTTPClient is designated as authenticated or not in the init(the later meaning the auth closures are not invoked) and similar to the old identity server auth, individual requests can be downgraded to remove the auth headers. All auth requests are now wrapped in an access token check that verifies its validity/requests a new token if required. All authenticated responses are also checked for the UNKNOWN_TOKEN and retried after again verifying/requesting an access token.
• MXRestClients used to interact with the homeserver are responsible for the refresh token exchange. A dispatch group and queue are used to ensure that the first request for an access token that requests an exchange with the server leads and all other requests for the token block until the leader completes. When they are unblocked the new token is in place.
• Refreshes can also take place in other processes like extensions. To ensure there is only 1 leader across processes we do a read + write of the credentials from disk effectively within a single transaction using NSFileCoordinator. If the read tells use the credential is good we us it, if not we refresh the token with the server and write it back within the transaction so that the next read get is and we don't have race condition.

TODO

• Finish preemptive request of tokens at set interval before expiration.
• Make sure with the new code and in place and MXSDKOptions.authEnableRefreshTokens enabled that access token auth continues to work until the users logs out.
• Make sure with the new code and in place and MXSDKOptions.authEnableRefreshTokens disabled that access token auth continues to work.

[ismailgulek]

I wonder if it would make sense to have default valued parameters on MXRestClient Swift initializer. We had to make a lot of changes in the tests. Totally up to you.