Bugzilla

While helping review the patches proposed for bug 1906657 :gl came with the idea of initializing `SnackbarBinding` from just one place - `HomeActivity` 
After bug 1906657 we'd initialize `SnackbarBinding` in multiple places because it needs a `FenixSnackbarDelegate` that needs to know where to place the snackbar layout.

As a general overview of the current flow:
For the scenarios in which we need the snackbar to be places in relation to other `View`s on the screen we make use of a simple `ViewGroup` with the `id` - `dynamicSnackbarContainer` which needs to be a child of a `CoordinatorLayout`. 
This `dynamicSnackbarContainer` as the parent of the snackbar will serve as the handle by which to move it inside the `CoordinatorLayout`.
For this we use a `CoordinatorLayout.Behavior` which allows moving any child as a side effect of changes to any of it's siblings - `dynamicSnackbarContainer` can be placed on top of it's "toolbarLayout" sibling.

This ^^ means that whenever a new screen (fragment) is opened the previous snackbar would not continue to show.
While not strictly needed at this time ensuring a snackbar persists on multiple screens (fragments) is a nice functionality to support and could be accomplished by 
- using the activity layout as the parent of the snackbar
- updating `FenixSnackbar` / `FenixSnackbarBehavior` to support rightly placing the snackbar whenever the user navigates to a new screen.

(This will be highly useful in the scenario of "indefinite" snackbars).

While helping review the patches proposed for bug 1906657 :gl came with the idea of initializing `SnackbarBinding` from just one place - `HomeActivity` 
After bug 1906657 we'd initialize `SnackbarBinding` in multiple places because it needs a `FenixSnackbarDelegate` that needs to know where to place the snackbar layout.

As a general overview of the current flow:
For the scenarios in which we need the snackbar to be places in relation to other `View`s on the screen we make use of a simple `ViewGroup` with the `id` - `dynamicSnackbarContainer` which needs to be a child of a `CoordinatorLayout`. 
This `dynamicSnackbarContainer` as the parent of the snackbar will serve as the handle by which to move it inside the `CoordinatorLayout`.
For this we use a `CoordinatorLayout.Behavior` which allows moving any child as a side effect of changes to any of it's siblings - `dynamicSnackbarContainer` can be placed on top of it's "toolbarLayout" sibling.

This ^^ means that whenever a new screen (fragment) is opened the previous snackbar would not continue to show.
While not strictly needed at this time ensuring a snackbar persists on multiple screens (fragments) is a nice functionality to support and could be accomplished by 
- using the activity layout as the parent of the snackbar and initializing `SnackbarBinding` only once in `HomeActivity`
- updating `FenixSnackbar` / `FenixSnackbarBehavior` to support rightly placing the snackbar whenever the user navigates to a new screen.

(This will be highly useful in the scenario of "indefinite" snackbars).