isle: Managing dependencies between crates

As part of https://github.com/bytecodealliance/rfcs/pull/28 I'm working on factoring out ISLE definitions from `cranelift-codegen` and moving them to `cranelift-asm`; concretely, the enum representing each ISA's machine instruction.

Currently each `inst.isle`, contains other helpers that use the enum definition, which semantically belong in `cranelift-codegen` and that ideally shouldn't be moved into `cranelift-asm`. This poses an interesting question regarding having ISLE dependencies between crates and what's the best way to go about it.

I had a chat with @cfallin, in which we discussed a couple of possibilities:

**Declaring each `MInst` as `extern`**

This would require (i) changing the `MInst` definition in `inst.isle` in `cranelift-codegen` to be `extern` (ii) moving each `MInst` definition to `cranelift-asm` and (iii) making the Rust types from the generated code in `cranelift-asm` available to the environment of the isle-generated code in `cranelift-codegen`. Similar to what exists for all the the other `extern` enums. In terms of disadvantages/concerns: whenever there's a change to the `MInst` enum in `cranelift-asm` the extern definition in `cranelift-codegen` needs to be updated too, which is kind of expected when seeing this from the angle of a dependency upgrade (i.e. sometimes changes are required in the consumer side), but in the end, we are keeping a verbatim copy of the definition and I wonder is this is going to introduce too much complexity when working with these definitions (there might be other disadvantages that I'm not clearly seeing too!).

**Having a single definition, serving both (or multiple) crates**

This idea is half-baked. But in general it would require moving the common ISLE pieces to a central location and copying them at build time to perform code generation. This approach has the potential to solve the definition duplication issue, but the question of how to concretely express dependencies between ISLE definitions remains open: for example, the structure of this new central location could be something like:

```sh
- inst.isle
- inst_enum.isle // MInst definition
- lower.isle
```

Ideally in this case, we'd be able to express dependency between `inst.isle` and `inst_enum.isle` in the language itself; but if there's a fundamental reason why we can't do it, this approach will require at the very least a "merge" of some sort between ISLE files, this makes this process less transparent. As a side note: is there a reason why ISLE couldn't be augmented to support a simple form of `import` directives?

---

There are a bunch of pros/cons to both items above, and my objective with this issue is not to decide on which one is better, but instead, make this conversation public to see what others think about this and what could be a sensible path forward.

In terms of how this affects the development of Winch; I don't think it affects it much. I would've preferred to start with `cranelift-asm`, but I see value in reducing complexity up-front, and delaying any refactoring until there's a clear picture of how all the pieces interact together. If there isn't a clear path forward, I'd prefer to keep the `winch`/`cranelift-codegen` dependency temporarily and avoid the `cranelift-asm` refactoring until we have an agreement on what an acceptable solution is here.