Remove most or all definitions in navActions.

[chrisbobbe]

React Navigation 5, which we've recently upgraded to (#4296), discourages the NavigationService strategy we've been using, as we mentioned in 140c28c.

From their doc about that strategy:

Do not use this method when you have access to a navigation prop or useNavigation since it will behave differently, and many helper methods specific to screens won't be available.

And from their doc on upgrading from v4 to v5:

It's highly recommended to use the methods on the navigation object instead of using action creators and dispatch. It should only be used for advanced use cases.

We should aim to remove all the action creators in navActions and use, e.g., navigation.navigate instead. See discussion here and here.

The callsites for the action creators in navActions seem to fall into three categories:

• We're in a React component that functions only as a "screen" component in React Navigation (i.e., the component is used in one way: it gets passed as the component prop to a <*.Screen /> component). Thus, it gets passed the navigation prop, and it's quite easy to just use it.
• We're in a React component that doesn't function as a "screen" component, so it doesn't automatically get the navigation prop.
  • These can often easily be converted to Hooks-based components, so that useNavigation can provide the navigation object.
  • Sometimes, (as in the case of ComposeMenu) the conversion to Hooks would take a bit of effort. We can consider
    • just pushing through with the conversion,
    • passing down the navigation prop from the nearest component that has it, or
    • making a trivial Hooks-based wrapper component that uses useNavigation, in the same file, and export that.
• We're not in a React component; e.g., we're somewhere deep in the event-handling code for a button being pressed on the action sheet, or for an outbound event coming from the WebView. It might actually end up being appropriate to keep the use of NavigationService for these callsites (as an "advanced use case"), rather than finding a way to thread the navigation object through from React. But we may find that something forces our hand.

[gnprice]

This was done in #5408.

There are still some things remaining in navActions. Quoting from commit messages in that PR, ending with fc78777:

Still using NavigationService are […]

 * Sites that aren't directly on a React component.  We'll let these
   be for the present.

   Many of these (like src/webview/handleOutboundEvents.js, and action
   sheets) are straightforwardly invoked from particular components,
   so should probably just take a navigation object as a parameter.
   For others (like doEventActionSideEffects) it's less direct; but
   they're still ultimately invoked from some React component, so the
   same solution can be applied, just with a bit more plumbing.

--

This commit doesn't cover all the call sites of these `navigateToFoo`.
Where we're dispatching the result on `NavigationService` instead of
on a component's `navigation` prop (whether gotten directly, passed
down from a parent component, or gotten equivalently through
`useNavigation`), there is no `push` method, so in those places we
stick for now with `dispatch`.

--

nav [nfc]: Cut now-disused navActions action creators

This covers most of the `navigateToFoo` nav-action creators, but
sadly not all of them: as discussed in the previous commit where we
simplified away most of the call sites, there are still some that
remain in places where we still use NavigationService.  So for now
we keep the nav-action creators that are used there.

But 22 out of the 34 navActions action creators we had are now deleted.