*Escaped* NUL is taken to mean end-of-string at the command line

I believe all (but at least one of) the following should be supported, but they produce zero-length output:

• echo -n \0
• printf '%s' \0
• echo -n \\\u0 (or with printf)
• echo -n \000 (octal, or with printf)
• echo -n \x00 (hex, or with printf)

Piping any of these into xxd or wc -c reveals that they produce no output.

The following does work, but it's not going through the fish tokenization/escape machinery:

printf '\0' | xxd

This isn't just an issue with the escaped NUL being ignored, variations on the above expressions like echo -n \0hello also produce no output.

I understand that a legacy C program would receive a NUL-terminated string in the argv array and be unable to distinguish between its inputs, but as we create length-prefixed rust strings from the tokenizer directly and are directly invoking the builtins used above with an args: &[wstr] parameter, there is no reason they should be subject to that same limitation. (This would have been true of the previous C++ codebase as well, where we were directly creating WString instances from the escaped nul and would have been technically able to preserve the contents past the NUL.)