[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).
The reason why the last AA library attempt failed was because it still had two AA implementations.
One in the compiler for doing AA stuff during CTFE and the runtime version.
We can only succeed when something like IndexExp on an AA is interpreted by calling a library function. Otherwise you'll always have problems with duplicate state and keeping them in sync.