wasm-wave: parse wit ItemNames as UntypedFuncCall names

[pchickey]

Based on #2529

Prior to this PR, wasm-wave defined a complete grammar for values, and additionally it provided a UntypedFuncCall::parse parser, which extends the grammar to include function calls. UntypedFuncCall was not described in the ebnf grammar, but instead is just tacked on as a special entrypoint to the Parser Parser::parse_raw_func_call. In short, the implementation was "a label, followed by parenthesis, which are empty or contain a tuple value".

The parenthesis and values are unambigiously the right choice for the syntax, but representing the function name as a single label is limiting: functions can exist anonymously (in no package, and in no interface), at the root of a package (in a package but not in an interface), or inside a package's interface. The parser gave us no way to parse or represent these cases, and it led to problems in implementations where a bare label might be ambigious, for example in the implementation of wasmtime run --invoke, which is the use case that led us to move wasm-wave into wasm-tools and take a dependency on wasmtime in the first case.

So, drawing on the work to define a parser in wit-parser for ItemName (which accepts strings like namespace:packagename/interface.funcname@0.1.0), which is capable of representing all of the above cases unambiguously, this PR reworks the UntypedFuncCall parser to be able to parse those cases as well.

The new parser is no longer a special entrypoint for Parser but instead a standalone function parse_raw_func_call in the same module. It re-uses the Parser machinery for parsing all wave values, but for the parsing the function name portion of the parse, it actually uses a totally separate logos::Lexer that accepts an ItemName-shaped string using a single regex. This approach was required because adding an ItemName-shaped token to the lexer conflicts with the parser which already accept a sequence of label, colon, label productions in several real cases, e.g. the record {a:none} would get rejected at the } for expecting a token / since the lexer would try to consume it as a package namespace and name.

Because wit-parser is an optional dependency on wasm-wave, finally parsing the UntypedFuncCall's name into a ItemName is done with an accessor method instead of in the parsing stage. Users who don't want to depend on wasm-wave can still consume the parsed function name as a &str, but don't get any help parsing it into a structure, in order to prevent duplicated code and the possibility of a confused deputy. (The alternative to this is making use of the entire untyped mod always depend on wit-parser, which seemed like it was too heavyweight for this particular case.)