It is not compatible with `react-router` v6.4, and is not something we
"really" need.

All uses of `useHistory` had to be replaced with `useNavigate`.

`react-router` v6 does not allow context to be passed as a prop to
`StaticRouter`, so a simple workaround was to just create our own React
Context.

Also remove a bunch of stub @types packages. Some are already provided in
the packages themselves, and the `react-router` specific ones caused some
compatability issues for some reason.

And fix a small ts error in the ConfirmModal code preventing build to complete.

I've noticed several issues with running `react-router` v6 on `node`
v16. It was about time anyways ..

For some reason I now had to update some stylelint stuff?

The tests relied on passing props into the page components, but this is
no longer accepted. Nevertheless, what they try to test is already
tested in our e2e tests, and besides it's quite uncommon to unit test entire
pages.

* Issues with a default pool not appearing when picking an appropriate
  event status type
* Pool merge time was being validated when it was not supposed to
* useMazemap would always be true, even when a normal location had been
  set
* Not actually in the editor, but it was previously not possible to view
  registrations on the event detail page because of the wrong check for
  `hasFullAccess`
* Better (and accurate) validation

Among other things, `SubmitButton` now accepts a `disabled` prop in case you
want to check for more things.

When the user had no prior meetings, `meetingSections.length` would
always be `0`, leading to an endless loop of fetching. Fixed by
introducing a simple flag.

Not sure why `pagination` was added to the dependency array, but
nevertheless this caused an endless loop of fetching.

The "fetch more" button seemed to not work without some proper feedback,
so I added that as well.

The query should be in the dependency array to force a fetch when
switching the page (the query).

oops

Extend the NavLink wrapper to accept a list of paths to "accept".

I believe the core of the issue was the spread operator for the query in
the fetch action, but I'm too tired to look into exactly why that was.

All fields were disabled when creating a new restricted mail
because the `isNew` check was wrong. Unlike for the forms
for email lists and users, the url param here will not be `new`
but rather `undefined`.

`endpoint` would be `undefined`, and a bad API request would be made.