Refactor ReferenceResolver to use native C++-enumerators in some places

[asl]

Refactor ReferenceResolver to get rid of majority of unnecessary heap allocations due to obsessive Enumerator<> usage:

• Use iterators and iterator ranges where possible
• Ensure we do not allocate on heap temporary objects and exploit move semantics as much as possible returning vectors by value
• Do some refactoring around Enumerator<>->toVector(): make it return result by value. It seems that the use in the tree is always about creating some temporaries. And it does not make any sense to allocate vectors on heap then
• Few small improvements here and there, e.g. removing dependence from boost adapters here

Partially addresses #4412

Ideally, we'd switch from memory allocation at getDeclarations / getDeclsByName, but it's a bit long way to go for now.

[asl]

Maybe it would make sense to wait until C++20 adoption and replace Enumerator with ranges and views over them.

[vlstill]

Generally I think this is a good change, thank you for your contribution. You may consider special-casing the common task of taking the first element of an enumerator in the enumerator itself. Do you have any performance measurements? I wonder what is the visible impact.

[vlstill]

Idea: This pattern seems to be repeated often enough it might be good to add something like std::optional<T> first() or maybe T first() (with BUG_CHECK) + std::optional<T> optFirst() to Enumerator and use it instead of toVector() -- there is no point in creating a vector just to get first element (and even a singleton vector allocates on heap, while this would do no allocation).

[asl]

Yes, I thought about this, but somehow decided to not to add... Will check it out.

[asl]

Actually, there is already single() method that does exactly this. It's just Enumerator interface is quite alien for C++ so noone seem to use is :)

[vlstill]

Suggested change

	const auto *decl = declVector[0]->to<IR::Declaration_Instance>();
	const auto *decl = declVector.front()->to<IR::Declaration_Instance>();

[vlstill]

Why is not not possible to call insert now?

[asl]

Because the way how Enumerator is implemented.... Enumerator::begin() / Enumerator::end() return so-called EnumeratorHandle which does not satisfy iterator requirements (no trait types like reference / value_type, etc.)

[vlstill]

Maybe it would make sense to wait until C++20 adoption and replace Enumerator with ranges and views over them.

I was thinking about that too. I was also wondering if there is 3rd party ranges implementation that is (C++17) GCC 9 compatible. I think this change is worth it by itself, but I would not go over the entire codebase trying to root out the old enumerators now.

[asl]

I wonder what is the visible impact.

We do not have much visible impact after memoization patch :) If we'd get rid of memoization, then there will be quite visible impact for large apps.

[fruffy]

@ChrisDodd Can you take a look at this PR?

[asl]

I am going to merge this unless noone would object as this would allow us to get rid additional boost bits.