Do not allocate MemorySegments for memory.data(i32, i32?)

[CountBleck]

Fixes #2827.

Changes proposed in this pull request:
⯈ Bump Compiler#memoryOffset instead of allocating zero-filled segments.

There is an issue with the initialPages calculation in initDefaultMemory, however. The existing condition to run that calculation depends on memorySegments.length, which is now zero if only memory.data(n: i32) is called, as in the memory-config-errors test.
Making that calculation occur regardless of the number of memory segments would cause a separate issue: due to the default memory offsets of options.memoryBase, 1024, or 8, modules that previously compiled with an initial memory of 0 pages would compile with a minimum of 1 page.

• I've read the contributing guidelines
• I've added my name and email to the NOTICE file

[dcodeIO]

Would this perhaps become simpler if we'd keep tracking such segments as MemorySegments but allowed the buffer to be null, indicating all zeroes?

More generally, when not indicating the presence of the segment to Binaryen, we'd always have to assume that memory is zeroed, as the zeroes won't be in the (memory ...). Might well be a non-issue in practice, though.

[CountBleck]

Would this perhaps become simpler[...]?

Oh, that's...a much better idea. Thanks and sorry about that.

[CountBleck]

Might well be a non-issue in practice, though.

@dcodeIO hmm, would this conflict when --importMemory is specified without --zeroFilledMemory?

[HerrCai0907]

LGTM.
A tip: Please avoid to force push after someone has already reviewed PR. This makes it difficult for reviewers to track.

[CountBleck]

@HerrCai0907 I changed the commit message; this is technically a breaking change.

[HerrCai0907]

@HerrCai0907 I changed the commit message; this is technically a breaking change.

You can modify it when click squash and merge😆 . Actually the message in commit is meaningless.