Refactor scheduler and worker creation

[wks]

This is part 2 of refactoring the scheduler: #532

But don't merge it yet, because there is a known problem: it breaks options from command line. See below. For now we temporarily disable setting the number of GC threads from the command line.

We now construct the GCWorkScheduler in one step, so that we no longer need to make every field Option<T> and set the value during initialize.

To make it possible, we eliminated cyclic references by considering MMTK, GCWorkScheduler and GCWorkerShared as nested data, like this:

MMTK {
  ...
  sheduler: GCWorkScheduler {
    ...
    workers: vec![
      GCWorkerShared {...},
      GCWorkerShared {...},
      GCWorkerShared {...},
      ...
    ],
  }
}

So inner structures do not refer to outer structures. We eliminated the GCWorkScheduler::mmtk field.

On the other hand, actors (threads) have references to all shared data they need. Both GCWorker and GCController contain a reference to the MMTK instance, so they no longer need to navigate from the scheduler to MMTK. And, obviously, private data of the actors (threads, including GCWorker and GCController) never refer to one another.

Known problem

We create GCWorkScheduler when MMTK is created. This is too early for now, because the MMTK instance is usually created statically by the VM. When it is created, we still don't know how many threads we have. The number of threads is determined by the mmtk.options.threads option, which can be set by either environment variable or command-line options. This is too late for the creation of GCWorkScheduler. The current PR will simply disregard any changes to the value of mmtk.options.threads after GCWorkScheduler is created.

To solve this problem, we need to make one (or both) of the following changes before applying this PR.

1. Introducing a MMTKBuilder, and build the MMTK instance after options are parsed.
2. Make it possible to add workers after GCWorkScheduler is created.
3. Change MMTK::scheduler to Option<Arc<GCWorkScheduler>>.

We will need to do (1) anyway, because currently options are also held by an UnsafeOptionsWrapper, which is unsafe.

Method (2) needs to make the worker group synchronised (probably using a RwLock). Adding a RwLock directly may add performance overhead because the work packet system frequently queries if all workers are parked. To do it efficiently, we should redesign the synchronisation algorithm and make the lock more coarse-grained. Issue #537 covers some of the details.

Method (2) will also enable the potential of dynamically adjusting the number of workers during execution, but let's not attempt that for now.

Method (3) simply pushes the Option<T> from the fields of GCWorkScheduler to the field of MMTK. It simply moves the problem to a different place.

[qinsoon]

LGTM