This is slightly annoying because I would really like to avoid having
configuration on the frontend side but this is the first feature to
require that which means we have to figure out how to do it per
environment. The frontend config duplicates the entire thing in 3
different files, instead here I chose to go with the taskgraph looking
way of using `by-env`. This is not perfect, it's very verbose but it
works.

As the comment says, this duplicates some values (repo URLs, version
file path...) with the frontend configuration but said config shouldn't
exist in the first place so I'm fine with that for now.

Do note that this config is a placeholder for now, used for testing.
It's missing a lot of merge behaviors and is using the wrong values for
beta-to-release so we can local test what happens with always-target-tip

`TaskStatus` here maps to taskcluster statuses, minus the difference
between pending/scheduled and failure/exception as those have the same
high level meaning.

Each merge automation is made up of 4 inputs.

- The product it targets (this might be a bit of a misnomer, because it's
running on repositories, not shipit products. But then firefox's merge
automation is running on multiple repositories so I decided to keep it
simple and keep it named product, have one for firefox). Right now the
goal is to support firefox only but this is future proofing because I
know that firefox-ios would also benefit from merge automation.
- The behavior to run. This is the name of the action to run, i.e
`main-to-beta`.
- The revision to run it from. Technically for firefox this doesn't really
matter because AFAIK it will always merge the tip of the branch but this
is where the action will be taken from and that is important for try.
- And finally whether that is a dry run or not.

Then we have a few properties regarding the status of it. When it gets
created, its task ID is null, status is pending. Then as it starts, we
need to record the task id of the action task we just created and update
the status based on the status of both the action task and the resulting
group.

The rest of the fields is caching, to avoid querying HG again since the
data is static and will never change (and querying hg is **slow**), and
to avoid issues if the configuration ever changes.

This gives the LDAP group allowed to create releases for a given product
the rights to run merge automation for said product.

This is a simple menu just showing a button to list all merge
automations and create new ones. I did not bother to make a "per
product" menu as for releases as firefox is the only supported one right
now.

The one part in here I'm unhappy with is the completion mechanism for
merge automations because it requires someone querying it to update it
which goes against good practice. I did this to avoid having to change
task groups to add a task similar to `mark-as-shipped` to merge
automation and having to uplift it in every tree.

In practice, that status is only ever used from the shipit UI so it'll
never fall out of sync unless the tasks expire before someone visits the
merge automation page again which is never going to happen.

The other alternative would be to hook the worker that currently handles
product details to poll taskcluster and update the status instead.

This was a bit of a pain because I'm not super familiar with react and
I'm **bad** at UI. The page to create automation is very similar to the
release creation one but for the listing I wanted to try something a bit
more user friendly so it's showing the task state from taskcluster for
both the action task and the resulting group.

While it would help with caching to do it from the backend as before,
the gains are not that significant as one would rarely get data for the
same commit multiple times and the drawbacks of making the shipit API
slower and hiding failures do to hg behind it are not worth it.

…k_id

As well as pagination, this now re raises the original exception instead
of a bare Exception to avoid eating context of said exception so
consumers can actually use it.

Instead of relying on the side effect of the GET request, make merge
automation require a call to mark them as complete to match what
releases do.

This also adds a merge-automation-id parameter to the merge automation
action trigger so that they can actually call that new route