[crashtracker] Better way to pass timeouts to receiver

[danielsn]

          Right--this one is hard.

Two failed ideas from my side.

1. The receiver code actually doesn't have control over the acquisition of its own args and it'd be a weird change to the entrypoint to make a new args struct required. So not a great choice of arg propagation.
2. Relying on the receiver configuration means waiting a few steps into the IPC sequence, which is not only weird but incorrect. I think I suggested this at one point, but I see how naive that was.

That really leaves the environment as the dominant way of passing this configuration.

With that in mind, some thoughts. I think the first two are constructive and the last is speculative.

First, we should probably by the naming that has been determined elsewhere. All the runtimes are using the CRASHTRACKINGlabel instead of CRASHTRACKER.

Second, how do you feel about marking this "private' (prepending one or two _ to the name)? End-users probably shouldn't be passing this. They should be using whatever configuration levers are provided by their library, and the library should pass this.

Third, here's an idea for tightening the interface. We could take a new option in the ReceiverConfig and then propagate it to the receiver's environment in make_receiver as part of the Prepared Args.

To sketch out that idea,

1. impl PreparedExecve would have a new fn new_with_env(config: &CrashtrackerReceiverConfig, env: Option<Vec<String, String>>) interface
2. Merge config.env and env (this other vec) in the PreparedExecve new_with_env, with the env coming last (winner-take-all in case of conflict).

_Originally posted by @sanchda in https://github.com/DataDog/libdatadog/pull/702#discussion_r1826256968_

[ivoanjo]

Apologies if this has already been discussed and discarded, but it occurred to me that a command-line argument may work as well for this :D