Add an encrypted version of the CredentialsManager

[lbalmaceda]

This PR adds a new class, similar but separate to the existing CredentialsManager one, that encrypts the data before persisting it and can also request the user authentication before accessing the stored credentials. This authentication behavior is disabled by default. By using the @RequiresAPI annotation I can make the compiler show an error if the developer is using this class on lower APIs. It requires minimum API 21 because that's when the "Confirm credentials" intent is first available.

Security discussion

• Encryption is done with an AES key of 256 bits of size. (We can gain some performance if I lower it to 128 I guess, but it's fast enough).
• The AES key is saved in the Storage encrypted using an RSA key pair of 2048 bits of size.
• The RSA key pair is saved in the Android KeyStore. I can generate keys and ask the OS to use them in the encryption/decryption process, but I can never access the actual key values.
• Detailed implementation can be seen in the CryptoUtil class.

Pending stuff

• CryptoUtil tests. White-box tests using PowerMock and Mockito. Not many alternatives here... The coverage report will show "zero coverage" because of Jacoco lack of support for the PowerMock test runner.
• CryptoManager tests. Including the "requires authentication" flow.
• Readme. Make clear which manager to use depending on the Android API level and how to support the authentication feature (i.e. add an example).
• Add some exception catching tests
• Try this manager in a sample like "session-handling" on API 21 and 23
• Rename CryptoManager to something cooler, like "EnhancedCredentialsManager". What do you think?

[cocojoe]

you store and retrieve the Credentials received in authentication calls. ->
you manage the Credentials received during authentication.

[cocojoe]

You'll need an AuthenticationAPIClient instance used to renew the credentials when they expire and a Storage instance. The Storage implementation is up to you.

This implementation is thread safe and can either be obtained through a Singleton method or be created every time it's needed. ->
This implementation is thread safe and can either be obtained through a shared method or on demand.

[cocojoe]

The enhanced version contains the same methods as the Basic manager but encrypts the data before storing it, and in ->
This version expands the minimum version and adds encryption to the data storage. In

[cocojoe]

Change this, don't like calling them basic etc don't need to say it.

In this version the manager requires a valid `context as shown below:

[cocojoe]

Few language changes to consider.

[cocojoe]

Modify your codecov.yml to allow for a little variance in overall and patch. For me -0.26% is acceptable so is 80% coverage in patch as sometimes it's just not possible. See threshold

https://github.com/auth0/Auth0.swift/blob/master/codecov.yml

[cocojoe]

Update your codecov to pass.