Add global export apis

[bnason-nf]

I'm very new to this code, so I'm not confident at all that this is the best way (or even a good way) to expose export globals, so please let me know if there is a better strategy or if I've just done it wrong. As a minor detail, I didn't see a good way in the AOT global_instantiate() to fill in the ref_type.

[lum1n0us]

the intention is for it to be writable from outside of WASM code.

Is it about to operate wasm export global in a host function? I may misunderstand the purpose. You used to mention it's about to go through all import/export and check and make sure all matched.

[wenyongh]

@bnason-nf the method of this PR in the AOT mode will allocate memory for the global instances, which increases footprint and the binary size. How about we define the wasm_global_inst_t structure in wasm_export.h, and let developer provide the structure pointer in the API, so that runtime just fills the structure and doesn't need to allocate memory? Somewhat like wasm_import_t/wasm_export_t and wasm_runtime_get_import_type/wasm_runtime_get_export_type:

typedef struct wasm_global_inst_t {
    wasm_valkind_t kind;;
    bool is_mutable;
    void *global_data;
} wasm_global_inst_t;
    
WASM_RUNTIME_API_EXTERN unt32_t
wasm_runtime_get_global_inst_count(const wasm_module_inst_t module_inst);

WASM_RUNTIME_API_EXTERN void
wasm_runtime_get_global_inst(const wasm_module_inst_t module_inst, uint32_t global_index,
                             wasm_global_inst_t *global_inst);

I am not sure whether exposing global_data pointer in global instance is good, if yes, developer should ensure the security, e.g. don't write invalid data to it or overwrite it.

[bnason-nf]

@wenyongh I implemented something very close to your idea, except that I kept the lookup by name instead of by index, since to me it feels more natural to use it that way from the calling application code.