fix(c-api) Trap's messages are always null terminated

[Hywan]

Description

wasm_trap_new expects a wasm_message_t. It's a type alias to
wasm_name_t with the exception that it represents a null-terminated
string.

When calling wasm_trap_new, no check was present to ensure the
string was well-formed. That's a first issue. But in the best
scenario, the string was correctly formed and was
null-terminated. This string was transformed to a Rust String —with
the null byte!— and passed to RuntimeError.

Then in wasm_trap_message, another null byte was pushed at the end
of the message. It's been introduced in
#1947. It results in a
doubly-null-terminated string, which is incorrect.

This patch does the following:

1. It checks that the string given to wasm_trap_new contains a
   null-terminated string or not, and will act accordingly. Note that
   it's possible to pass a non-null-terminated string, and it will
   still work because this detail is vicious. The idea is to get a
   well-formed RuntimeError in anycase.
   • If no null byte is found, the string is passed to RuntimeError
     as a valid Rust string,
   • If a null byte is found at the end of the string, a new string is
     passed to RuntimeError but without the final null byte,
   • If a null byte is found but not at the end, it's considered as an
     error,
   • If the string contains invalid UTF-8 bytes, it's considered as an
     error.
2. It updates wasm_trap_message to always add a null byte at the end
   of the returned owned string.
3. It adds test cases when passing a null-terminated or a
   non-null-terminated string to wasm_trap_new and to compare the
   results to wasm_trap_message.

It fixes #2439.

Review

• Add a short description of the change to the CHANGELOG.md file

[Hywan]

bors try

[bors]

try

Build succeeded:

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

[syrusakbary]

Merging directly as bors already passed