[new AA] implement core.internal.aa

This PR introduces new AA implementation. At the first stage, compiler will not know about `core.internal.aa.AssociativeArray` and will use only object.aaNew and object.aaLiteral methods.
Thus, this AA implenetation should replace rt.aaA implemetation.
When first stage will be finished, we will start work to endowing `core.internal.aa.AssociativeArray` with all the abilities of language's AA. For example:
```
int[string][string] table;
table["foo"]["bar"] = 3;

AssociativeArray!(string, AssociativeArray!(string, int)) table2;
table2["foo"]["bar"] = 3; //exeption, because "foo" doesn't exist in table2
```
However, now I dont's talk about second stage. I want to finish first stage, wait one release cycle (to catching all possible troubles), and start to work under second stage when the next D version (after first stage finish) will be released.
>I haven't reviewed this, but just to answer @rainers question, the optimization we added does not affect any code except when one iterates the elements, either with .values, .keys, or any of the ranges. It also helps when rehashing, because the empty buckets are not examined. The cache is not updated at all costs, only when doing so is cheap.

Ok, I've added this cache to this implementation, because I don't want to review existing AA work at this stage. Let it will be work as it rt.aaA.

>For existing AA, this is not a problem, as it lives on the heap.

My AA may be stored in static memory (this work will allow returning AA from CTFE), but I think it is not trouble. This algorithm update cache only in non-const methods, and non-const method can not be called for const or immutable AA object, thus we may not be afraid to write to ROM.