wit-parser: add ItemName type and parser

[pchickey]

This adds a new type and parser to the wit-parser crate for ItemName.

The intent is to define a single place where an optionally-qualified path to an item's name is parsed. At its core an item name is:

pub struct ItemName {
    pub package: Option<crate::PackageName>,
    pub interface: Option<String>,
    pub name: String,
}

and the only nontrivial details is that, if the package is provided and that package has a version, the version is the suffix of the entire item name, e.g. namespace:packagename/interface.funcname@0.1.0.

This PR does not add any integration of this type to the Resolve struct. That is left for a future PR.

My goal in adding this type without yet integrating it with Resolve is to use this type in other crates that already depend on wit-parser:

1. in wasm-wave: parse wit ItemNames as UntypedFuncCall names #2530 this parser is useful in extracting structured information from a wave function call
2. in Wasmtime, this type could impl the https://docs.rs/wasmtime/latest/wasmtime/component/trait.InstanceExportLookup.html trait, so that e.g. the export wasi:cli/run.run can be looked up without chaining API calls to perform a lookup of wasi:cli/run -> run.
3. and, together, those two mechanisms leaning on this common type can solve the problem in wasmtime run --invoke where, if there happen to be more than one function exported across all interfaces named run, its impossible to disambiguate, https://github.com/bytecodealliance/wasmtime/blob/main/src/commands/run.rs#L799-L808

[fitzgen]

LGTM but I'm not super familiar with this code, so if you feel like having @alexcrichton take a look as well would be good, then feel free to wait to merge this until after that's happened.

[alexcrichton]

Could this re-use existing parts of the parser to share both syntax and implementation? for example UsePath might be appropriate to parse here and then manual parsing of .{name} happens after that. It would change syntax subtly around the versions but it'd be a bit more consistent with the rest of WIT

[pchickey]

@alexcrichton when I started this work I made a wrapper around UsePath with a suffix for the function name, and give it the right methods for separate use. I decided against it because wasi:io/poll@0.2.0.poll looked way too gross. We have never written that syntax before, and I don't want to ask anyone to, even if through some lens its consistent. Its already odd enough that we dont always write it wasi:io@0.2.0/poll.poll but my view on consistency is that if we want versions to be a suffix it should always be a suffix of the entire expression.

If I misinterpreted your suggestion and you think there's a different concrete syntax that works better, I'm happy to look at that.

[alexcrichton]

Sounds reasonable to me 👍