Provide proper encapsulation of StableMIR APIs

The current crate structure of StableMIR is making it very hard to properly encapsulate our stable structures. All the internal details of stable items have to somehow be exposed in order to allow rustc_smir to build them.

For example, the definition of Ty exposes its internal representation:

pub struct Ty(pub usize);

There is no mechanism for us today to ensure that this usize corresponds to an index inside StableMIR. The Context trait is also exposed, even though we expect users to never invoke them directly.

The main problems I see with the lack of encapsulation are:

1. Usability. It's confusing for users to know exactly what they can rely on, and what they shouldn't.
2. Defining the boundaries of what is semantically versioned.
3. APIs are very fragile. Users can easily make a mistake that will break a type invariant, which will result in one of the following:
   a. Their code will trigger an ICE
   b. The API may return inconsistent result
   c. We will have to constantly check for these invariants ourselves as much as possible and return Result for everything we do.

We should investigate what is the best mechanism to fix this.

### Tasks
- [ ] Enable proper encapsulation (merge crates?)
- [ ] Audit the StableMIR code and change the visibility of items that shouldn't be public

Start by auditing the StableMIR crate structure and the public Ty and Context APIs described in the issue. Determine whether merging crates is needed, then identify StableMIR items whose visibility can be reduced. Done means stable structures are properly encapsulated and the listed type invariants cannot be bypassed through the public API.