Fix the WebAssembly page size at 64KiB.

[titzer]

This PR updates the design repository to define a fixed WebAssembly page size of 64KiB.

The rationale for this change is to achieve efficient virtual-memory-based bounds checks without resorting to nondeterminism in the page_size operator. Experience has shown that programs tend to become dependent on one particular value of PAGE_SIZE (e.g. 4KB) and not be fastidious users of provided constructs that abstract over varying page sizes. Such programs break on moving from one platform to another, and we'd like to avoid those programs breaking when moving from one engine to another.

[titzer]

The rationale for 64KiB is even though the vast majority of platforms and CPUs provide 4KiB pages, not all CPUs do, and some operating systems further restrict memory mappings to something larger than the physical page size. In particular:

sparc: 8KiB
some arm64/linux configs: 64KiB (https://www.kernel.org/doc/Documentation/arm64/memory.txt)

[sunfishcode]

This sentence reads a little awkward. Possible suggestion: Programs can depend on this fixed page size and still remain portable across all WebAssembly engines [Full Stop]. And, engines can rely on this invariant to employ efficient virtual memory techniques for bounds checking.

[sunfishcode]

lgtm, with just a few minor wording suggestions

[titzer]

Suggestions integrated.

[ghost]

I support this for memory sizing. It might have been useful for a garbage collector written in wasm to be able to use a smaller page size for a write barrier - not sure just how much of a difference this makes.

I think the rationale overstates the utility because virtual-memory-based bounds checking seems to only be an option for wasm32 in a 64 bit runtime.

It might also simplify a start-of-usable-memory option - a 64k start might be adequate for many systems.

Are/could/should data segments be defined to be page aligned.

[lukewagner]

lgtm, although it might be nice to add a FutureFeatures.md section for "Large page support" linked to by the last sentence of Rationale.md that gives a bit more of the details.

[sunfishcode]

@JSStats Virtual-memory-based sandboxing has numerous potential uses. One example would be an optimizer that combines the checks for several accesses that have the same base but different constant offsets (within a reasonable size), using a guard region to catch offsets that run out of bounds. Another example would be an optimizer that eliminates bounds checks in loops with small-stride access patterns by having a guard page at the end of memory and assuming that either the loop will terminate on its own or it'll hit the guard page, and so it doesn't need any bounds checking inside the loop.

[titzer]

Added links back and forth re: large pages in FutureFeatres.