Preallocate `DefId`s for lang items and use lang items in lowering

[oli-obk]

Right now, our lowering code uses string-paths to call e.g. Iterator::next when lowering for loops:

rust/src/librustc/hir/lowering.rs

Lines 4653 to 4655 in c6ac575

	let next_path = &["iter", "Iterator", "next"];
	let next_path = P(self.expr_std_path(head_sp, next_path, None, ThinVec::new()));
	let next_expr = P(self.expr_call(head_sp, next_path, hir_vec![ref_mut_iter]));

This triggers a name resolution call

rust/src/librustc/hir/lowering.rs

Lines 5263 to 5273 in c6ac575

	let mut path = self.resolver
	.resolve_str_path(span, self.crate_root, components, is_value);
	path.segments.last_mut().unwrap().args = params;
	for seg in path.segments.iter_mut() {
	if seg.hir_id.is_some() {
	seg.hir_id = Some(self.next_id());
	}
	}
	path

which will then give us a resolved path, but that's

1. potentially expensive, since it happens every time a specific path is generated (which happens a lot for ? and for expansions/lowerings)
2. seems uncool since it's stringly typed

I think it would be neat if we could instead create the lang_items table early in the process and just grab the appropriate item out of that table.

cc @Centril @eddyb @petrochenkov

As a first experiment to check out the impact we could create a cache for path resolutions so we only run the path resolution code once and just overwrite all HirIds in the generated path with new HirIds whenever we fetch a cached resolution.

[Centril]

I'm going to take a look at this as a side-project :)

[oli-obk]

So... one thing I just thought about:

We could introduce a third variant to QPath: LangItem. QPath::LangItem just contains a

rust/src/librustc/middle/lang_items.rs

Line 36 in 9ebf478

pub enum LangItem {

We can then just create such paths without actually having to do any work. Code further down will have access to a TyCtxt and thus be able to resolve said lang in a way that queries understand.