`Use.is_glob` changes meaning of `Use.id` and `Use.name`

id of Use (from ItemEnum::Use) may refer either directly to the item that has been imported as item.name, or a parent module that has not been added to the namespace as item.name, but merely holds items that were imported.

This effectively creates two different types/variants of the Use, without there being types/variants in the type system for the different meanings. It causes bugs whenever the .id or .name is used without also checking is_glob and implementing two very distinct code paths for interpreting the same fields of the same type.

Additionally, figuring out which items have actually been imported requires reimplementing name resolution, which is quite inconvenient.

Use is already nicely broken down into individual imported items, so that use m::{foo, bar, baz} creates 3 Use items instead of one. It makes processing of the items simpler, because it avoids creating a one-to-many relationship between items. Unfortunately, that's not the case for glob imports. It would be great to have the same expansion and normalization happening for glob imports, and have use m::* create as many Use items as needed to represent every imported item individually. This way, processing of items from glob and non-glob imports would be unified for consumers of the rustdoc JSON.

Start by inspecting the ItemEnum::Use representation and the current handling of glob imports in rustdoc JSON. Compare glob imports with the existing expansion of use m::{foo, bar, baz}; the work is done when glob imports produce individual Use items for each imported item and consumers no longer need separate is_glob-dependent interpretations.