Refactor HIR item-like traversal

[cjgillot]

HIR is globally traversed using the tcx.hir().{,par_}visit_all_item_likes{,_in_module} family of functions. These functions create a lot of dependency edges (they call the hir_crate query, or call hir_owner for each item-like). These dependencies are not always useful: many use sites only require items, and don't care for impl items, trait items or foreign items.

This can be avoided by replacing those functions by a scheme based on ItemIds. Actual user will be responsible for calling tcx.hir().item to get the HIR. The amount of access to HIR will be further reduced by pre-filtering using tcx.def_kind query.

Steps:

• create a hir_crate_items query which traverses tcx.hir_crate(()).owners to collect all the ids and return a rustc_middle::hir::ModuleItems;
• use tcx.hir_crate_items in tcx.hir().items to return an iterator of hir::ItemId;
• use tcx.hir_crate_items to introduce a tcx.hir().par_items(impl Fn(hir::ItemId)) to traverse all items in parallel;
• gradually replace uses of tcx.hir().{,par_}visit_all_item_likes with tcx.hir().par_items or tcx.hir().items;
  when possible, create a fast path using tcx.def_kind(item_id.def_id) before calling tcx.hir().item(item_id);
• introduce tcx.hir().items_in_module and tcx.hir().par_items_in_module which do the same thing with tcx.hir_module_items instead of tcx.hir_crate_items;
• gradually replace uses of tcx.hir().visit_all_item_likes_in_module with tcx.hir().par_items_in_module or tcx.hir().items_in_module;
• retire hir::ItemLikeVisitor.

The steps starting with "gradually" can be split into several PRs.
I am available on zulip for any question.

[kckeiks]

@rustbot claim

[kckeiks]

Not sure why rustbot is ignoring me but I'd like to pick this up. I'll have some bandwidth in the next couple of weeks to work on this.

[kckeiks]

@cjgillot I think #96825, #96531, and #95655 have address the tasks in this issue. We have created hir_crate_items, replaced visit_all_item_likes where appropriate, and retired ItemLikeVisitor. Please let me know if we can close this issue or if there is anything else we should address.

If the parallelization of the compiler still in early stages, maybe it would be better to address the parallelization-related tasks in this issue in a future issue along with other parallelization-related endeavors? If so, I'll leave it up to you to review and approve or close #97998.