Improve `auto` type deduction in HeuristicResolver

[HighCommander4]

In clangd/clangd#897 I added rudimentary support for auto type deduction to HeuristicResolver, but the accuracy could be improved further.

As an example, the implementation does not currently propagate the const when deducing const auto.

This can be seen in clangd with the following code example:

template <typename T>
struct A {
  void waldo();
  void waldo() const;
};
template <typename T>
void foo(A<T> a) {
  const auto copy = a;
  copy.waldo();
}

Go-to-definition on the waldo token in copy.waldo() offers both overloads as candidates, but it should only offer the const overload.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Nathan Ridge (HighCommander4)

In https://github.com/clangd/clangd/issues/897 I added rudimentary support for `auto` type deduction to `HeuristicResolver`, but the accuracy could be improved further.

As an example, the implementation does not currently propagate the const when deducing const auto.

This can be seen in clangd with the following code example:

template <typename T>
struct A {
  void waldo();
  void waldo() const;
};
template <typename T>
void foo(A<T> a) {
  const auto copy = a;
  copy.waldo();
}

Go-to-definition on the waldo token in copy.waldo() offers both overloads as candidates, but it should only offer the const overload.

[HighCommander4]

Note that code completion in a similar scenario has the same issue:

template <typename T>
struct A {
  void waldo();
  void waldo(int) const;
};
template <typename T>
void foo(A<T> a) {
  const auto copy = a;
  copy.^
}

Code completion at the ^ offers both overloads but it should only offer waldo(int).

[HighCommander4]

Un-assigning myself because after a brief investigation this looks a bit more involved than I thought.

While we could hard-code handling for a top-level qualifier like const specifically, I'd prefer to take a more general approach of trying to perform the type deduction process against a dependent initializer type. However, this will involve calling into Sema (specifically Sema::DeduceAutoType()). I'd like to give HeuristicResolver the ability to call into Sema at some point but I'm going to pursue some lower-hanging fruit improvements first.