We don't have many of these at present, and should probably have
more.  We'll add some more in the next commit.  Before that, add
a bit of developer documentation about what these are and how
they work.

…props.

The type of `props.route.params` is very much like the type of a
React component's `props` itself: it's part of the definition of the
component's interface, and the most natural place for it to live is
next to the definition of the component.

With React Navigation upstream's guide for using type-checking:
  https://reactnavigation.org/docs/typescript/
(of which I'm looking at the 5.x version; sadly those docs don't
allow permalinks to the current version, only to versions which are
already outdated), this unfortunately gets flipped around, so that
the route-params types are all defined in a central place associated
with the navigator, and the individual components' definitions refer
to that to get their respective types.

That works in that it does at least get type-checked, but it makes
it harder than it should be to read and understand the components,
either to use them or to make changes to them.  The effect is a lot
like if for an ordinary function, the types of its parameters
weren't defined up at the top but instead off in some other file.

So, let's do things the other way around: the route-params type gets
defined right there among the other props, next to the component's
body; and the navigator's central list of params types refers to the
components' types to get their respective route-params types.

In this commit, we add a couple of small type aliases to use for
that arrangement, and demonstrate using them on one of our smaller
navigators.  There are also some type-tests to check that these
aliases behave as expected.

Also discussing a bug in the interaction of `tools/test` with `eslint`
that appears when you're on a branch that's touched one of the
ignored files.