[dmd-internals] AssociativeArray in druntime should go before the next release

[Daniel Murphy]

I've been trying to fix bug 5590 and the deeper I go, the worse it looks.

- D's associative arrays cannot be represented with a struct in the
current compiler.  They require magic initialization when null, and
the current mapping doesn't give a sane way for this to happen.

- They are still implemented in the compiler.  Associative array
indexing, creation etc is still done by the compiler inserting
druntime calls.  Only some of these are hijacked by the struct in
object.di.

- It complicates the compiler.  There are a bunch of places that
attempt to detect both object.AssociativeArray and V[K] and handle
both sanely, and several more that don't and crash the compiler.
Slight changes cause backend crashes or wrong code generation.  The
interpreter has implement every operation anyway, so nothing is gained
by having the struct in object.d.

- The implementation can't be improved because it is tied to the
druntime calls.  As far as I'm aware AssociativeArray was created so
AAs could be improved without having to modify the compiler, and to
make the compiler simpler.  The compiler is still required for AA
literals, indexing, magic initialization, so I don't think this has
worked.

- If they're in the library, they should be CTFEable.  Isn't this the
whole point?  Even with each operation on AAs handled manually in the
interpreter, inlineing will still pull the functions in
AssociativeArray apart and reduce them to druntime calls.

The reason it needs to be done before the next release, is that it
will break Andrei's recent addition
(https://github.com/D-Programming-Language/druntime/pull/128).  (Which
doesn't even work at compile time, and I don't think it can unless the
_aaXXX functions are implemented as builtins)

Even if that was rolled back, removing the AssociativeArray hack will fix bugs.

AAs as a druntime/library type without compiler magic can be done at a
later time when the design and implementation have been considered
more carefully.

I'm quite happy to do the work in rolling this back (and implementing
a better solution) but I feel the current state is a disaster.

Walter, Andrei, can I get a nod on this?