Add import/export mutable globals

[abelstuker]

Closes #299.

This extends the implementation of global variables in the VM with mutability and import / export semantics.
It provides encapsulation of globals, mutability checks and import resolution.
This change restructures the global variable to align with the accepted proposal https://github.com/WebAssembly/mutable-global/blob/master/proposals/mutable-global/Overview.md.

The host program can now define globals for import in the module as follows:

// Define some mutable global state (initialized to 0)
def_glob(some_mutable_state, I32, true, {.int32 = 0});
// Install the global
install_global(some_mutable_state);

;; Import the mutable global state
(global $some_mutable_state (import "env" "some_mutable_state") i32)

;; Modify the mutable global in a function
(global.set $some_mutable_state 2)

Conversely, the host can also access globals exported in the module:

;; Export some global state (initialized to 3)
(global $some_other_state (mut i32) (i32.const 3))
(export "some_other_state" (global $some_other_state))

// Retrieve the mutable global
uint32_t some_other_state_idx = this->get_export_global_idx(m, "some_other_state");
Global *some_other_state = m->globals[some_other_state_idx];
// Modify the mutable global
some_other_state->value->value.uint32 = 5;

[tolauwae]

Looks pretty good, I made a few comments.
However, I realised while reviewing that we can't properly test this without multiple module support (#27), right?

[abelstuker]

I realised while reviewing that we can't properly test this without multiple module support (#27)

It is possible to test this since globals cannot only be shared between modules but also between a module and the host.
So a global that is defined by the host (for example in arduino.cpp, using def_glob and install_global) can be imported by the module. Or the other way around, a global exported by the module can be used by the VM using WARDuino::get_export_global_idx in WARDuino.cpp.

[tolauwae]

I realised while reviewing that we can't properly test this without multiple module support (#27)

It is possible to test this since globals cannot only be shared between modules but also between a module and the host. So a global that is defined by the host (for example in arduino.cpp, using def_glob and install_global) can be imported by the module. Or the other way around, a global exported by the module can be used by the VM using WARDuino::get_export_global_idx in WARDuino.cpp.

This still doesn't cover all use cases, but it should suffice for now indeed.