Extracts `AndroidIconDecoder`, `IconDecoder` and `DesiredSize` out of `browser-icons`
into a new component `support-images`, which provides helpers for handling images. `AndroidIconDecoder` and `IconDecoder`
are renamed to `AndroidImageDecoder` and `ImageDecoder` in `support-images`.

Update changelog

We fall back to the "aes128gcm" encoding if the value is not provided.

We still test with it, so we keep it around.

⚠️ **BREAKING CHANGE** ⚠

️

Users will need to supply a configuration with a ping uploader to Glean
now.
A default lib-fetch-httpurlconnection implementation can be used like
this:

```kotlin
import mozilla.components.lib.fetch.httpurlconnection.HttpURLConnectionClient;
import mozilla.components.service.glean.config.Configuration;
import mozilla.components.service.glean.net.ConceptFetchHttpUploader;

val config = Configuration(httpClient = ConceptFetchHttpUploader(lazy { HttpURLConnectionClient() }))
Glean.initialize(context, true, config)
```

For Java this becomes:

```java
import mozilla.components.lib.fetch.httpurlconnection.HttpURLConnectionClient;
import mozilla.components.service.glean.config.Configuration;
import mozilla.components.service.glean.net.ConceptFetchHttpUploader;

ConceptFetchHttpUploader httpClient = ConceptFetchHttpUploader.fromClient(new HttpURLConnectionClient());
Configuration config = new Configuration(httpClient);
Glean.INSTANCE.initialize(context, true, config);
```
Co-authored-by: Alessio Placitelli <alessio.placitelli@gmail.com>

- Maps MediaState from BrowserState when creating the Tabs list

We'll now have a more in-depth understanding of user's gestures based on which
we can trigger different BrowserToolbar behaviors depending on if the user is
scrolling or zooming.

The ConstraintLayout parent will still inform us about when the scroll begins
and when the scroll ends but then actually incrementally updating the toolbar's
translation will be done in response to GestureDetector callbacks.
This also allows us to easily differentiate between horizontal and vertical
scrolls and only react for the latter.

If the user's gestures as inferred as zoom gestures (multi-finger scale or
quick-scale) the toolbar should not be animated.
This scenario is though affected by the fact that normally scroll gestures have
a much higher sensitivity (a 1 pixel movement is enough for a gesture to be
considered a scroll gesture) and so it is possible that even in the case of a
desired zoom gesture the scroll callbacks will be fired first.
When the gesture is identified as a zoom gesture we will immediately snap the
toolbar up/down but there might be a minor visual glitch because of this.
In an effort to reduce such races between scroll and zoom gestures I've lowered
the sensitivity of the ScaleDetector, this having the other effect that
multi-finger scrolls must now be more precise. Pinching while zooming will now
more often mean a zoom gesture and not animate the toolbar.

BrowserMenu will now use a RecyclerView with dynamic width, automatically set
between
- `mozac_browser_menu_width_min`
- `mozac_browser_menu_width_max`
allowing for a better fit for all menu items.

By default `mozac_browser_menu_width_min` and `mozac_browser_menu_width_max`
have the same value ensuring the same previous behavior for all clients -
fixed width, the value of mozac_browser_menu_width.
`mozac_browser_menu_width_min` and `mozac_browser_menu_width_max` must have
different values for BrowserMenu to have dynamic width.