[new AA] aaLiteral support

This PR depends on D-Programming-Language/druntime#933
This PR based on #3892, however in use zero AA init value.
I think, this way more pretty and safe.
New AA implemetation use template `object.aaLiteral` function to create AA.
This implemetation allows to return AA literals from CTFE, if `object.aaLiteral` can be evaluated at compile time. New aa implementation (D-Programming-Language/druntime#934) allow creating instances of AA at compile time (of cource, if hashes is CTFEable, and elements are eveluatable at compile time).
Template-based way implementation prevent using TypeInfo-based code, thus we need to know static Key and Value types to create AA instance.
As I said, this AA implementation doesn't use special initializer and empty AA like `int[int] aa;` doesn't know his static type.
When we try to insert value in AA, compiler generates call of a special function : `aaGetX` and if it takes `null` AA, it can't create new AA instance without auxilarity function.
Thus when compiler does it, it passes pointer to `aaLiteral(Key, Value)` (without arguments) to `aaGetX` and `aaGetX` can use this function to initialize empty AA.
This solution causes a few minor behaviour changes:
`test/runnable/imports/link12144a.d`:
If struct is used as AA key, `opEquals` should accept const this and rvl. Same for `toHash`. Also we need to satisfy function promises like `pure` or `nothrow`. For example, we can not create AA literal with key, with non-nothrow `toHash` in nothrow code. This is not breakage, this is partial fix of typesystem hole.

`test/runnable/sdtor.d`:
`test/runnable/testaa.d`:
`test/runnable/testaa2.d`:
New implenetation calls postblit for keys (as needed), and may calls excess postblit in aa literal (because D hasn't rvalue-ref yet).
>You're attaching an expression (a function pointer) to a type. That's completely against the grain to the rest of the compiler and will probably break in many subtle ways.

I do not see anything unnatural. For example each Type know his `defaultInit`.
`TypeSArray` contains his dim: `Expression *dim;`

>There is exactly one such place.

Hmm. Maybe I may simple do it, but this implementation will not much differ from current.
I wil do the following: 
1. `aaGetX(K, V)(...)` will be defined in object.di
2. When this function is instanstantiated it will have a signature similar `_aaGetX`
3. `FuncDeclaration *` field will be added to `TypeAArray`
4. `void visit(IndexExp *ie)` will do `s = taa->getx->toSymbol();` instead of `s = taa->aaGetSymbol("GetX", 1);`
 
>The problem is to do the lowering without breaking the CTFE interpreter.  

This PR doesn't introduce _lowering_. It still use  `_aaXXX` API like the old implemetation, but some functions is declared as template now. However, this templated functions uses in directly in backend. CTFE shouldn't know about them.
The general goal of this stage is introduce new AA implementation without major compiler changes.
The sideline task is implement CTFE AA literals.

The compiler refactoring, using lowering instead of API functions is a large work and will be done at the next stage.

>Another approach would be to lower aa[key] = 5 to *aaGetX(aa is null ? (aa = aaLiteral!(Key, Value)()) : aa, key) = 5.

This looks simple, but when we start to implement it, will come out different problems.
For example, what if we have a `const(Foo)[string] aa`? If we lower it as you suggest, we will get a compile-time error: unable to assign  to `const` value. However assignment a constant value to aa is allowed.
Similar improvements can be implemented while in service.