Support path references external to `sources` for Docker builds in `requires` and `requirement_installer_args`

### What is the problem or limitation you are having?

Once https://github.com/beeware/briefcase/pull/2059 is merged and released, the `requirement_installer_args` option will be available. Local, relative paths used in the option (e.g., as an argument to `--find-links`) are automatically transformed into absolute paths, which enables seamless use for all build targets **that build on the host**. Docker, however, does not build on the host, so these path references are meaningless to it.

This also affects usages of local paths in `requires`, for which Briefcase handles local paths in a manner similar to `requirement_installer_args`.

### Describe the solution you'd like

Add support for these by mounting referenced local paths into the container. Any solution for this will require tracking any local references found in `requires` or `requirement_installer_args` and exposing them in such a way that the Docker integration is able to include those mounts in calls to commands in the build container.

I can see two ways of actually mounting them:
1. Mount the host paths to a location like `/opt/{mount-name}` in the container, and re-write any usage of those paths in the command arguments to reference the location in the container. Re-writing the arguments could be risky, but Briefcase already does this when it converts relative paths to absolute paths anyway, so it doesn't seem like this would really be too unique.
2. Mount the host paths to the same location in the container, which avoids needing to re-write the actual command that is executed. It will appear as though the host's path is explicitly available to the container. However, this might also cause a subtle confusion in error messages. For example, if a command ends with an error about not being able to find a particular referenced path, and that path appears to be a host path rather than one obviously in the container's context, the path could present as a red herring, when the underlying issue is actually that the path doesn't exist anywhere at all.

The first option seems better to me, even though it's yet another level of argument re-writing. If the re-writing is implemented in `DockerAppContext._dockerize_args` itself, then it could work automatically for any path referenced on the host. In other words, it may be possible to implement this in such a way that it solves it for any command running on the host that happens to use a local path reference, rather than only for `requires` and `requirement_installer_args`. On the other hand, if more care is desired, a solution scoped specifically to just those two arguments should be explored. This is perhaps best decided in PR review, particularly if an answer isn't immediately obvious.

### Describe alternatives you've considered

See above.

### Additional context

A temporary workaround for `requirement_installer_args` is to avoid the path transformation in that option by using the `=` style for the argument (e.g., `--find-links=./wheels`) and then adding `wheels` to `sources` and `cleanup_paths`. This is just a workaround and shouldn't be relied on for long-term usage.

Start at DockerAppContext._dockerize_args and trace how local paths in requires and requirement_installer_args are transformed before commands run in the build container. Compare the proposed mount and path-rewriting approaches, then verify that referenced host paths are available inside Docker without breaking existing host builds.

Written by the indexing model from the issue text.