Allow multiple data segments

[lukewagner]

It's my understanding that we want to be able to have multiple data segments and to control the offset in linear memory into which each segment is loaded. For simplicity of validation and because I don't see the need for this flexibility, the validation rules require the segments to be disjoint and ordered by offset.

For good form, I should also add negative validation tests (breaking the rules). Rather than giving each one a separate file and pattern-matching on the exact text output, I think this is another good usecase for a new script command that you give a module that should fail to validate and then perhaps a string key to identify which error you're expecting. Need some agreement on #14 before pursuing that.

[titzer]

At the s-expression level, this probably makes sense. However at the binary level I think it makes sense to allow multiple overlapping data segments. In fact, I think we should allow unrestricted data segments in the binary format so that a binary can really "process itself", including the data representing its own code, etc. This freedom may allow us to "polyfill" new binary tricks and features on top of WASM 1.0.

[lukewagner]

@titzer I agree with wanting the over-the-wire binary format to be able to do arbitrary stuff, but this is generally something we've said would be done above level 0 (along with deduplication, macros, etc). That way the manipulation can be quite arbitrary and not complicate the spec. (And perhaps later, based on a lot of trial and error, we standardize an optional layer 1 which can be decoded natively.)

[lukewagner]

Updated to address comments. I also made modul.memory a memory option, instead of having dead values, as the way to say "no declared linear memory". This was also nice for being able to simply reject multiple memory declarations (which previously overwrote).