[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've tested that and it's work (Of course with the new druntime part).  However I can't add the test yet, because this PR should works with old AA too, untill new AA implenetation will not merged.
Once again. When we merged this PR AA behaviour will not changed. After that, when we will merge druntime part (which I gave for auto-testing), AA willbe constructable at compile time and old AA will be able to be removed.
Druntime part (https://github.com/IgorStepanov/druntime/tree/aaintegration3) is splitted to two PRs (for easy review): first part is D-Programming-Language/druntime#934, second part will be pulled when this and 934 PRs will be merged.