Cameleon: Stricter Alternative Implementation of VariantN

[Nordlöw via Digitalmars-d-learn]

Because I'm not satisfied with the current state of 
memory-layout-flexibility/pureness/safeness/nogc/nothrow-ness of 
`VariantN` I've hacked together a lightweight version of 
`VariantN`, I currently call `Cameleon`.

The code is here:

https://github.com/nordlow/justd/blob/master/cameleon.d

Its currently limited to my specific needs (strings and 
value-types) through

https://github.com/nordlow/justd/blob/master/cameleon.d#L5
https://github.com/nordlow/justd/blob/master/cameleon.d#L35

because it's hard to decrypt the inner `OpID`-workings of 
`VariantN`.

Questions:

- Is the logic of opAssign and get ok for string?
- How does the inner workings of the GC harmonize with my calls 
to `memcpy` in `opAssign()` here

https://github.com/nordlow/justd/blob/master/cameleon.d#L80
https://github.com/nordlow/justd/blob/master/cameleon.d#L107

and my zeroing of the internal data buffer in `clear()` here

https://github.com/nordlow/justd/blob/master/cameleon.d#L143

?

- Do I have to call some GC-logic in order to make the GC aware 
of the new string-reference in `opAssign`?

- Is this logic for `char[]` different from `(immutable char)[]`?
- And what do I need to think about if I allow classes as members?