Reimplement the pants_bin_name functionality in Rust.

[benjyw]

This feature allows users to set a custom binary name
for use in help messages and documentation. So that
if their org has a custom wrapper script or binary,
we can direct users to use that.

Reimplementing this in Rust allows us to further
simplify OptionsBootstrapper.

Note that the old implementation relied on setting
an env var on the current process by manipulating
os.environ. This served two purposes:

1. Communicating the value within the process, and
2. Communicating the value from the client to pantsd,
   since the latter inherits the environment of the former.

( 2) is important because pantsd uses bin_name() at
import time, and options (including the pants_bin_name
option) may not be available yet. )

But - setting an environment variable on the current
process is not thread-safe on POSIX, and there is no
way to make it so. Therefore we change the implementation
to use a static Mutex for 1), and an explicit pass-through
of that value when spawning pantsd for 2).

[huonw]

Ah, just confirming my understanding, the initialisation process looks something like:

1. the native client starts up, and parses options
2. parsing these options includes detecting the https://www.pantsbuild.org/stable/reference/global-options#pants_bin_name value (if set) and setting the static
3. pants_daemon_client.py then reads that option value via the static...
4. ... to propagate into pantsd via the env var

[benjyw]

Exactly right. This is in fact how it always worked, but the implementation obscured this. At a casual glance you could think that the daemon was reading the value and setting the env var. And this did happen, but too late. The reason it worked in practice was that the client read it first and then the spawned server received it via env var.

[benjyw]

Oh and I should mention that all this is tested (both with and without pantsd) in tests/python/pants_test/integration/bin_name_integration_test.py