Thread-safe Thread Manager

[Fixes #57435374]
[#56005352]

Msf::ThreadManager was a subclass of Array, which is not thread-safe and
the manner in which Threads were added and removed from the
Msf::ThreadManager was not synchronized with a Mutex, so the Array could
be become inconsistent, although rare for MRI.  More problematic, the
interface to kill a managed thread used only the index of the Thread in
the Array, so if a Thread was killed and a new Thread assigned that that
index between listing the Thread and asking for the Thread to killed,
then the wrong Thread could be killed.

Because Array is not thread-safe, abandon using Msf::ThreadManager.
Replace it with Metasplioit::Framework::Thread::Manager, which uses
MonitorMixin and a ThreadGroup, which is thread-safe because it is how
Ruby itself tracks Threads.  Instead of using indexes, or the object_id,
which would have the same re-use problem as the Array system, kill
threads based on their name.  Names can be reused, but in-theory if a
name is reused, the Thread semantic repreents the same work and should
be what the user intended to kill unlike with index collisions in the
old system.

If it turns out that killing by name still kills the wrong Thread
because of name reuse when the Thread is not semantically the same, then
the Thread metadata could add random UUIDs to ensure no Thread is ever
confused with another Thread.

The use of ThreadGroups also means there is no strong references to dead
Threads, so they are automatically garbage collected without any need to
have a monitor thread.

To allow for easier testing Msf::Framework's children were changed to
use lazy initialization to that factories can be used to construct a
framework, but not start up all the Threads, etc as as the case with the
eager initialization.  The lazy initialization makes use of MonitorMixin
to synchronize the ||= to ensure that it is thread-safe.