json-from-wast: name emitted files after the output stem

[eyupcanakman]

json-from-wast named its emitted *.wasm and *.wat files after the source .wast stem, so -o out.json still wrote <source>.0.wasm rather than out.0.wasm the way wast2json does. This derives the stem from the -o output path when one is given and falls back to the source stem otherwise. Added a cli test for both cases.

Refs #1471.

[alexcrichton]

Thanks! The CI failure might be some CRLF thing, but I'm not entirely sure.

Out of curiosity though, could you explain a bit more why you want an exact match? Naively it seems good to strip the leading $ and it seems better to render "-1" instead of u32::MAX. I'm not opposed to these changes necessarily, but for future-selves I think it'd be good to have written down motivation. (even if it's "just because it's nice to byte-for-byte match" if that's the case)

[eyupcanakman]

It was just to match wast2json more closely, but your question made me check who consumes this, and chicory (which runs json-from-wast) parses the i32/i64 values as signed, so the unsigned change would break their Integer.parseInt (and probably the $-prefix). I'd lean toward trimming this to just the filename fix and dropping the int and name changes, unless you'd rather keep the full match. The Windows fail was a path-separator thing in the test, not CRLF, and I'll fix that.

[alexcrichton]

That sounds reasonable to me, yeah 👍

[eyupcanakman]

Trimmed this to just the filename change and reverted the int and name bits along with the snapshots. The Windows fail was the cli test runner handing a backslash path to source_filename, so I normalized the % substitution to forward slashes like wast already does.