Implement support for IPI types

[jan-auer]

This PR exposes the ID stream (IPI).

The TPI and IPI streams share the same structure, but they contain different records. Most importantly, the type of index used indicates whether a type lives in the IPI or the TPI. In microsoft-pdb this is either CV_typ_t for types, or CV_ItemId for ids. Of course, both are u32.

To create a clear interface that avoids confusion, identifiers are clearly separated into TypeIndex(u32) and IdIndex(u32). Since now the id stream needs the same root struct, iterator and finder, this is abstracted into ItemInformation<I>, ItemIter<I> and ItemFinder<I>, where I is the index being used. On top of that, there are type definitions to simplify the handling of such types: type Type<'t> = Item<'t, TypeIndex>, etc.

Apart from some renaming for consistency, usage stays mostly the same.

Unrelated, this PR contains two more fixes. They can be moved into separate PRs if desired:

• Flags and modes of pointer types have been implemented (and fixed)
• Some types have a "unique name", i.e. the partially mangled type name. It is exposed now.

[jan-auer]

@willglynn Before I finish this up, wondering if you have reservations against the general approach of splitting the streams up into an explicit TPI and IPI stream rather than merging them magically internally.

Unforunately, it's not possible to know which stream to use by just looking at the numbers. That means, that it would be necessary to look in both streams and then prefer one result over the other. However, at the declaration side, it is always clear which stream the index refers to, hence the differentiation.

[willglynn]

Great work!

I favor distinguishing TypeIndex(u32) and IdIndex(u32), mostly because I favor having fewer u32s to mix up. And as you note, each field containing such a reference is strongly typed already, and the TPI and IPI streams are separate at the MSF level anyway. Modeling them separately seems appropriate despite their internal similarities.

No worries about the little changes mixed in here. We'll need to cut a release once your current body of work lands, and there aren't any other projects currently in flight, so separate vs combined is all the same to me.

[jan-auer]

@willglynn All feedback should be addressed now.
I hope that the type defs don't make it odd to use TypeIndex now.