Consider making TraitsExecutor.submit thread-safe

[mdickinson]

Right now TraitsExecutor.submit is not thread-safe: it modifies internal state that's not protected by locks. We could potentially make submit thread safe. There are some trade-offs here:

• For the originally intended use-cases (running a computation in the background), there's not a lot of value in being able to submit jobs from within the background job. (Typically, the background job should either not have access to mutable state "owned" by the main thread, or at least should not be modifying that state; the executor itself counts as one piece of such state.)
• It'll significantly complicate the executor code and tests, and open up a range of new and exciting failure modes.
• But in typical job submission frameworks, it's normal for the job submission machinery to be thread-safe, so users of Traits Futures are likely to expect that to be true.

I'm still inclined not to make TraitsExecutor.submit thread-safe until a need emerges, but it is something that's feasible if we need it.

(See also #301)