Cleanup proposal for .fromBytes().load(byte[])

**Glide Version**: 3.5+ -> 4.0
**Issue details**: `StreamByteArrayLoader` constructor is deprecated and will be removed along with `.load(byte[], id)` method so it won't be possible to pass the `id` to `ByteArrayFetcher` without rewriting the removed deprecated code. So the `ByteArrayFetcher` constructor should be deprecated too in 3.6.0 and be removed in 4.0 along with the other proposed changes in this issue.
The documentation fo `ByteArrayFetcher` says:

> Requires an id to be passed in to identify the data in the byte array because there is no cheap/simple way to obtain a useful id from the data itself.

which was probably true pre-`.signature()`, but that statement is not needed any more. Currently all `byte[]`s are treated equal, because the fetcher doesn't provide a sensible id (default is `""`) in `Engine.load`. Which means `.fromBytes()` and `.load(byte[])` can't be used with memory cache and also requires a signature to be passed in (I guess this is the reason why those two things are inside `fromBytes`).

To reach consistency with other methods I suggest:

``` java
ByteArrayFetcher.getId() { return bytes.toString(); }
```

This will have the following effects:
- different arrays will be treated as different data
_equivalent to file path or unique uri_
- the `ByteArrayFetcher.String id` field will be clearly useless, as should be, based on the `.signature()` API
_(other Fetchers also have their model as `getId()`_
- `.signature(new StringSignature(UUID.randomUUID().toString()))` could be removed from `RequestManager.fromBytes()` since the `byte[]`'s memory address will uniqely identify the data
_all other uses of `signature` in `RequestManager` is either a deprecation workaround or sensible default (`ApplicationVersionSignature`)_
- `.skipMemoryCache(true /*skipMemoryCache*/)` may be removed from `RequestManager.fromBytes()`, because there may be transformations and other operations like creating bitmaps, which are worth caching. It's currently not possible to say `fromBytes().skipMemoryCache(false)` and get valid results.
- Anyone loading a `byte[]` then modifiying the contents and loading it again need to provide a signature, but for most cases I see that won't be the case. And the cache gains are more useful.

@sjudd Please let me know what you think about the idea.

Start by reading ByteArrayFetcher, StreamByteArrayLoader, RequestManager.fromBytes(), and Engine.load to trace how byte-array IDs, signatures, and memory-cache settings are currently handled. Compare the proposed deprecation and cache behavior changes across these entry points; done means the API cleanup is consistent and byte arrays can use the intended cache behavior without losing support for signatures when contents change.

Written by the indexing model from the issue text.