Expose the ordinal of MessageIndex / EnumIndex / ExtensionIndex for dense side tables

`MessageIndex`, `EnumIndex`, and `ExtensionIndex` are opaque `u32` newtypes with `pub(crate)` contents. That is the right default, but it leaves a consumer that wants a per-message side table (per-type caches, lowering metadata, lookup tables keyed by message type) with no dense key: the options today are a `HashMap`, or keeping a sorted `Vec` and binary-searching it on every access, because the ordinal inside the index is not readable and the pool does not enumerate its messages with their indices.

Either of these would do, and both are additive:

- `MessageIndex::index(self) -> usize` (and the same on `EnumIndex` / `ExtensionIndex`), documented as dense in `0..pool.message_count()` for the pool that issued it and meaningless across pools (the same caveat the type's docs already give for comparison); plus `DescriptorPool::message_count()` and friends so a side table can be sized up front.
- or `DescriptorPool::messages(&self) -> impl Iterator` and `extensions_of(&self, MessageIndex) -> impl Iterator`, so the table can be built by enumeration and then indexed by the ordinal.

The first is the smaller change and enough on its own. Related to, but independent of, #413 (which is about obtaining a `MessageIndex` from a generated type at all).