Add support for memory growth

[bnason-nf]

No description provided.

[lum1n0us]

LGTM

[yamt]

i guess it's better to use uint64_t for memory64.

[wenyongh]

In the current design of memory64, the max page count is UINT32_MAX since the max size of linear memory size is 274TB roughly and should be able to meet most of the requirements:

wasm-micro-runtime/core/iwasm/interpreter/wasm.h

Lines 97 to 108 in 65bf04e

	#define DEFAULT_NUM_BYTES_PER_PAGE 65536
	#define DEFAULT_MAX_PAGES 65536
	#define DEFAULT_MEM64_MAX_PAGES UINT32_MAX
	/* Max size of linear memory */
	#define MAX_LINEAR_MEMORY_SIZE (4 * (uint64)BH_GB)
	/* Roughly 274 TB */
	#define MAX_LINEAR_MEM64_MEMORY_SIZE \
	(DEFAULT_MEM64_MAX_PAGES * (uint64)64 * (uint64)BH_KB)
	/* Macro to check memory flag and return appropriate memory size */
	#define GET_MAX_LINEAR_MEMORY_SIZE(is_memory64) \
	(is_memory64 ? MAX_LINEAR_MEM64_MEMORY_SIZE : MAX_LINEAR_MEMORY_SIZE)

And the type of page count in WASMMemoryInstance is kept uint32:

wasm-micro-runtime/core/iwasm/interpreter/wasm_runtime.h

Lines 116 to 118 in 65bf04e

	uint32 cur_page_count;
	/* Maximum page count */
	uint32 max_page_count;

So here using uint32 should be also OK.

[yamt]

whatever limitations the current implementation has, it's better to make the user-facing api align with the spec and future-proof, IMO.

[wenyongh]

OK, @bnason-nf, could you upload another PR to change uint32_t to uint64_t? Thanks.

[bnason-nf]

Submitted #3573.

As mentioned by @wenyongh, there are other existing 32 bit memory limitations. Aside from the many uint32 types used internally for memory sizes, including by the direct aot_enlarge_memory() and wasm_enlarge_memory() calls by this new function, there are also many places in the public API that use uint32_t for memory sizes. So as I'm sure everyone is aware, PR #3573 is just a tiny piece of a much larger effort that will need to take place to make WAMR truly 64 bit compatible.