Proposal: one EXPORTS setting to rule them all

**Background**: Right now to keep alive & export a compiled function one would use `EXPORTED_FUNCTIONS`, while to ensure a JS library function exists one would use `DEFAULT_LIBRARY_FUNCS_TO_INCLUDE`, and there is `EXPORTED_RUNTIME_METHODS` for exporting parts of the JS runtime. This is needlessly complex, and confusing since a C API may be implemented in either compiled code or a JS library, and currently you need to know which in order to properly include and export it.

**Proposal**:
* A new `EXPORTS` setting, which receives a list of things to ensure exist and are exported in the final output. These can be in compiled code, the JS library, or the JS runtime - the user doesn't need to know.
* Deprecate all the other relevant options (but still support them for backwards compatibility for a long time at least), namely `EXPORTED_FUNCTIONS`, `DEFAULT_LIBRARY_FUNCS_TO_INCLUDE`, `EXPORTED_RUNTIME_METHODS`.
* No `_` prefixing, like `EXPORTED_RUNTIME_METHODS` etc., and unlike `EXPORTED_FUNCTIONS`. This moves us further along the path to get us rid of the old prefixing annoyance.

For example, `-s EXPORTS=['main', 'emscripten_main_loop', 'AsciiToString']` would export a compiled function, a JS library function, and a runtime function, respectively (and note the lack of `_` prefixes).

Thoughts?

cc @juj @sbc100 @jgravelle-google @sbc100 @dschuff