feat(c-api) Remove the deprecated API

[Hywan]

Description

Until this patch, our C API comes in 2 flavors: deprecated and
wasm_c_api. With the coming 2.x version of Wasmer, we would like to
remove the deprecated API, and keep the wasm_c_api only.

This patch removes the deprecated API from the wasmer-c-api
crate. It also cleans up the Makefile and the documentation
system. Previously, the documentation for the deprecated API was
relying on Doxygen, which was one new dependency the user had to
install. For the wasm_c_api, it relies on rustdoc, which is way
better because all examples are run and tested as part of our test
suite.

This clean up also removes the need to deal with system-libffi both
in the crate itself and in the Makefile, which was an edge case for
macOS on aarch64, and a needle in the foot for some of our users.

Finally, the build.rs is now simplified because we no longer need to
exclude symbols from one header to another. It also means that we only
provide the wasmer_wasm.h header file now; the wasmer.h and
wasmer.hh headers are removed.

[jubianchi]

Seems good so far. There are comments in the code on parts I think you are still working on (in lib/c-api/src/wasm_c_api/externals/table.rs for example).

Also, I'd like to wait for the other Prs to be merged to do a second round of review.

[syrusakbary]

It also means that we only
provide the wasmer_wasm.h header file now; the wasmer.h and
wasmer.hh headers are removed.

I think it will be better to rename wasmer_wasm.h to wasmer.h and have wasmer_wasm.h to be an empty file just importing wasmer.h and emit a compiler warning notifying user to use wasmer.h instead

[Hywan]

Actually, using the wasm suffix make sense. If we want to support or to implement another API, we keep the wasmer_ prefix, and use a suffix to specify the kind of API we support. So I'm in favor of keeping wasmer_wasm.h. Thoughts?

[syrusakbary]

I think only one API should be encouraged to use at the same time, so using a prefix for wasmer_* doesn’t make that much sense (unless we split it into smaller chunks in the future).

Also, Wasmer is always going to be focused on Wasm, so I see as redundantly recommending wasmer_wasm (we should keep the import working for compatibility thought).

[Hywan]

Let's address that in another PR then, so that it's easier to review.

[syrusakbary]

Oh, I think I read it wrong. So yeah, let’s keep Wasmer_wasm but just as an empty wrapper that just imports Wasmer.h for now!

[Hywan]

bors try

[Hywan]

bors r+

[syrusakbary]

bors r+

[syrusakbary]

bors r+

[syrusakbary]

bors r+

[syrusakbary]

Bors was failing because the PR changed a file inside .workflows which Github doesn't allow somehow

[bors]

Build failed:

• Test on linux-x64

[syrusakbary]

bors try

[bors]

try

Already running a review

[syrusakbary]

bors try-

[syrusakbary]

bors r+

[bors]

Canceled.

[syrusakbary]

bors r+

[bors]

Build succeeded:

• Audit
• Code lint
• Test cross-compile on linux
• Test cross-compile on macos
• Test on linux-x64
• Test on macos-x64
• Test on windows-x64