On enabling post-MVP features by default

[dcodeIO]

In a recent Binaryen PR the question of when to enable post-MVP features in tooling came up. In particular, since the mutable-global proposal had been finished meanwhile, the suggestion there was to enable the feature by default in Binaryen (and have a Default feature set to target finished features). On the AssemblyScript side, a good strategy seems to be to enable finished proposals by default as soon as our toolchain supports them in a stable manner, closely aligning with the standardization process. Until there is some sort of feature detection this also means: If a targeted engine supports more than the finished proposals, those must be explicitly enabled in tooling. Likewise, if a targeted engine supports less than the finished proposals, those must be explicitly disabled in tooling.

As suggested by @kripken I'm opening this issue so we can coordinate.

[tlively]

There seem to be two reasonable approaches here:

1. Update the default feature sets in tools as proposals become standardized. Pros: less to think about for users targeting up-to-date, feature-complete engines. Cons: inconsistent across versions, so realistically users would need to explicitly enable features in their build systems anyway or make upgrades a headache.
2. Keep MVP as the default feature set forever. Pros: consistent and predictable, easy to upgrade. Cons: Requires detailed knowledge of what features are supported, will become outdated eventually.

Both of these seem bad. Perhaps a middle ground would be to keep MVP as the default, but bundle features into "releases" so users could target "wasm2020" or something without having to know the details. We would still need a centralized caniwasm.com sort of thing to document what features or releases each engine supports, though.