Minimise the scope of the <VM> generic type

[qinsoon]

At the moment, most of the types has a <VM> generic type to it, even if the type does not actually use <VM> (but some of its functions uses it). We should do a cleanup to remove the generic type where possible. These are a few points raised from our discussion:

• If a function in the type uses <VM>, we can make the function generic rather than make the type generic.
• If possible, only types that are logically used by the VM should have the type parameters, such as MMTK<VM>, Mutator<VM>. Types such as Collector<VM>, Space<VM> do not sound logically right.
• Types without <VM> can be unit tested without mocking.
• If a call to <VM> is not performance critical, it is possible for us to use dyn VM rather than generic type. However this requires some possibly API-breaking changes, as currently we never instantiate a VM object (all functions in VMBinding are static functions).

[wks]

We discussed ProcessEdgesWork in today's meeting. There is a related issue for that #599, but the main problem with ProcessEdgesWork is that it contains too much information about a trace. It contains more than just <VM>, but also the concrete work packet types for the current trace.