Propose a new LLVM CPU configuration: Lime1 (#235)

* Propose a new LLVM CPU configuration: Lime1

## Overview

I propose a new target CPU configuration for LLVM, and any toolchain or engine that wishes to share it, named "lime1".

Lime1 would enable mutable-globals, bulk-memory-opt*, multivalue, sign-ext, nontrapping-fptoint, extended-const, and call-indirect-overlong**. The specific set is open to debate here. The idea is, once we stabilize it, Lime1 would be stable and we would not add or remove features from that point on. Lime1 could be followed by Lime2 and so on in the future if we wish to add or remove features after that. And we can always define new non-Lime CPUs as well, if there are needs for different sets.

\* bulk-memory-opt would be a new feature that just includes `memory.copy` and `memory.fill`, and not the rest of bulk-memory

\*\* call-indirect-overlong would be a new feature that just introduces the new `call_indirect` encoding from reference-types and not the actual reference types.

## Further background

The LLVM Wasm target defaults to a "generic" CPU, which adds features over time as major engines support them. That's good for some users, but other users would benefit from more stable CPU options. Currently the only stable CPU in LLVM is "mvp", however that's pretty old at this point. We've always planned to add more CPUs, but haven't had convenient occasions. The Wasm spec gives us "Wasm 1.0" and "Wasm 2.0" and so on, however while those names may sound like curated user-facing versions, in practice they're more like snapshots of the spec at moments when the spec process reaches certain points.

There have been discussions at the CG level about defining official subsets of the language, for engines that don't want to implement threads or other things. If the CG ends up defining specific subsets, we can certainly add new stable CPUs based on them. However, I expect that'll will be some time in the future yet, and it seems beneficial to define something LLVM can use sooner as well.

So because there is no convenient external milestones, let's invent one! The name "Lime" is short for "*Li*near *me*mory", and refers to how this target is relatively focused on linear-memory languages. Just as the Wasm spec itself has no concept of "wasm32", it won't have any concept of "lime" either. Lime will just be an informal tooling and engine convention.

Lime.md

@@ -0,0 +1,67 @@
+# The Lime Series
+
+Lime is a series of defined and stable subsets of [WebAssembly features] that producers
+and consumers can both use to promote interoperability. It is intended to be implemented
+by producers such as LLVM, using features such as LLVM's concept of target CPUs. Once a
+Lime configuration is defined, it will be stable and not add or remove any features.
+
+Lime configuration names include a version number, such as "Lime1". When there is a
+need to add or remove features, a new Lime configuration with a new version number will
+be defined, such as "Lime2".
+
+Lime aims for features which do not involve significant new runtime cost or complexity,
+and can be implemented in mobile devices and other highly constrained environments.
+
+## The configurations
+
+The following Lime configurations have been defined:
+ - [Lime1](#lime1)
+
+### Lime1
+
+The Lime1 target consists of [WebAssembly 1.0] plus the following standardized
+([phase-5]) features:
+
+ - [mutable-globals]
+ - [multivalue]
+ - [sign-ext]
+ - [nontrapping-fptoint]
+ - [bulk-memory-opt]
+ - [extended-const]
+ - [call-indirect-overlong]
+
+[WebAssembly features]: https://webassembly.org/features/
+[WebAssembly 1.0]: https://www.w3.org/TR/wasm-core-1/
+[phase-5]: https://github.com/WebAssembly/meetings/blob/main/process/phases.md#5-the-feature-is-standardized-working-group
+[mutable-globals]: https://github.com/WebAssembly/mutable-global/blob/master/proposals/mutable-global/Overview.md
+[multivalue]: https://github.com/WebAssembly/spec/blob/master/proposals/multi-value/Overview.md
+[sign-ext]: https://github.com/WebAssembly/spec/blob/master/proposals/sign-extension-ops/Overview.md
+[nontrapping-fptoint]: https://github.com/WebAssembly/spec/blob/master/proposals/nontrapping-float-to-int-conversion/Overview.md
+[bulk-memory-opt]: #bulk-memory-opt
+[extended-const]: https://github.com/WebAssembly/extended-const/blob/main/proposals/extended-const/Overview.md
+[call-indirect-overlong]: #call-indirect-overlong
+
+## Feature subsets
+
+[WebAssembly features] sometimes contain several features combined into a
+single proposal to simplify the standardization process, but can have very
+different implementation considerations. This section defines subsets of
+standardized features for use in Lime configurations.
+
+### bulk-memory-opt
+
+bulk-memory-opt is a subset of the [bulk-memory] feature that contains just the
+`memory.copy` and `memory.fill` instructions.
+
+It does not include the table instructions, `memory.init`, or `data.drop`.
+
+### call-indirect-overlong
+
+call-indirect-overlong is a subset of the [reference-types] feature that contains
+just the change to the `call_indirect` instruction encoding to change the zero
+byte to an LEB encoding which may have an overlong encoding.
+
+It does not include the actual reference types.
+
+[bulk-memory]: https://github.com/WebAssembly/bulk-memory-operations/blob/master/proposals/bulk-memory-operations/Overview.md
+[reference-types]: https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md