[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'm looking for tests that create an AA at compile time and then access it at runtime. I understand why they're not in this PR, but do they exist?

`core.internal.aa` contains tests which check back-end work in CTFE mode and interoperability between CTFE-created AA and runtime code.
`core.internal.hash` contains tests of `hashOf` compile-time/run-time compatibility.

I want to add front-end aa tests to dmd when this dmd and druntime parts will be merged. I don't want to add language feature tests to druntime. However I've tested CTFE-created AAs manually.