Remove cast_ref_to_mut related to SFT

[wks]

Parent: #850

SFTMap implementations cast &self to &mut self for modifying its underlying sft: Vec<&'a (dyn SFT + Sync + 'static)>. This table is accessed by multiple threads, but it needs to be updated occasionally. It is problematic in two ways:

1. Each element can be read and updated at the same time. This is a data race which has undefined behaviour.
2. After one thread grows the space, other threads can access the SFT for the extended part while the space that grew the space is still updating the SFT entries. See:

   mmtk-core/src/policy/space.rs

   Line 81 in f1a0bb7

   // We need this lock: Othrewise, it is possible that one thread acquires pages in a new chunk, but not yet

One way to solve the first problem is changing the elements of the Vec to AtomicPtr. However, & dyn Trait is 16 bytes in size.

The "double-checked locking" algorithm can be used for data structures that are lazily initialised. I think the use pattern of SFT matches lazy initialisation in certain ways, and may be applicable.

[playXE]

&dyn Trait can be replaced with AtomicU128. The problem is most likely in HashMap, it has to be replaced with DashMap to allow safe concurrent access. But also, the problem is that Vec can be pushed into which is not really safe as well in multiple threads scenario

[k-sareen]

A fix was merged in #879, but I'm keeping this issue open since removing unsafe would be ideal.

[qinsoon]

Done in #931.