[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).
> I do not see anything unnatural. For example each Type know his defaultInit.
> TypeSArray contains his dim: Expression *dim;

OK convinced, let's keep it like this for now.