Ignore wizer subdirectory for now

prtest:full

Add C++ example using function renaming to handle ctors properly.

Previously, it was difficult to properly use Wizer with C++ programs
that have static constructors. These constructors are normally

Add C++ example using function renaming to handle ctors properly.

Previously, it was difficult to properly use Wizer with C++ programs
that have static constructors. These constructors are normally run
before `main()` is invoked by some libc/linker plumbing at the usual
entry point. This causes a set of undesirable problems:

- In the Wizer initialization entry point, our globals' constructors
have not yet run.

- If we manually invoke the constructors to resolve the first issue,
then they will be *re*-invoked when the program's main entry point is
run on the initialized module. This may cause surprising or
inconsistent results.

In order to properly handle this, we add a `wizer.h` header with a
convenient macro that allows specifying a user initialization function,
and adds an exported top-level Wizer initialization entry point and an
exported replacement main entry point.

The generated initialization entry point invokes any global constructors
(using the function `__wasm_call_ctors()` which is generated by
`wasm-ld`) then invokes the user's initialization function.

The generated main entry point is meant to replace `_start` and performs
the same work, *except* that it does not re-invoke constructors.
Instead, it immediately invokes `main()` (because everything has already
been initialized) and then calls destructors and exits.

Taken together, the two entry points match the code that is present in
`_start` in an ordinary Wasm binary compiled by wasi-sdk. This approach
should be relatively stable, as long as the symbols
`__wasm_call_ctors()`, `__wasm_call_dtors()`, and `__original_main()`
are not renamed in the WASI SDK (this seems unlikely).

show more ...