CacheKey collisions with multiple entity types using same ID

**Describe the bug**
If you have 2 entities (e.g. Order and Product) that have the same ID (e.g. 5), AppSync will confuse cached instances of those entities.

**To Reproduce**
Steps to reproduce the behavior:
1. Create a schema with Order and Product entities as well as list/get queries for each.
2. In your database (or just hardcoded in a Lambda), create an Order record and a Product record, each with an ID of 5.
3. Use the Android AppSync client to retrieve those Orders and Products.
4. Observe the `selectRecordForKey` function in `SqlNormalizedCache`. It will simply query the SQlite database for a key of "5" rather than "Order:5" or "Product:5".

This causes a host of downstream issues for the user, but this is the most direct way to observe it.

**Expected behavior**
The cache database should be queried with a key prepended with the entity type, as the documentation states here: ~~https://aws-amplify.github.io/docs/android/api#client-architecture~~ mysteriously moved to ->
https://aws-amplify.github.io/docs/sdk/android/api#client-architecture

**Environment(please complete the following information):**
- AppSync SDK Version: 2.10.0

**Failed workaround**
I tried simply implementing my own `CacheKeyResolver` to specify a custom CacheKey, but that led to separate strange behavior in which the entities cached by calling a list query (e.g. getOrders) were not found/used by a ByID query (e.g. getOrder(id)). That might merit an issue of its own, but let's see what happens here.

Start in SqlNormalizedCache at selectRecordForKey and compare the cache-key behavior described for Order and Product records sharing ID 5. Read the CacheKeyResolver workaround details and the linked Android client-architecture documentation. Done means the SQLite cache distinguishes entity types while list and ByID queries continue to find the same entities.

Written by the indexing model from the issue text.