Fix type inference for parent scopes and method definitions with receivers

[vinistock]

Motivation

In the original Ruby LSP indexer, we did not handle the resolution of parent scopes used in definitions. For example:

module Bar; end

module Foo
  # This defines `Bar::Baz` because the `Bar` reference gets resolved to top level `Bar`
  # through the lexical scope. Rubydex does this correctly, but the Ruby LSP doesn't
  # run resolution on its node context and misunderstands this as `Foo::Bar::Baz`
  class Bar::Baz
  end
end

Similarly this example

module Foo
  module Bar; end
end

module Baz
  include Foo

  # This doesn't define `Baz::Bar::Qux`. It has access to `Bar` through inheritance
  # and defines `Foo::Bar::Qux`.
  #
  # Note that references to `Baz::Bar::Qux` also work, but not because that's the fully
  # qualified name of the constant. `Baz::Bar` finds `Foo::Bar` through inheritance,
  # allowing you to refer to `Qux`
  class Bar::Qux; end
end

We also did not handle method definition receivers correctly, which don't advance the lexical scope, but modify the type of self. For example:

class Bar; end

class Foo
  def Bar.baz
    # self here is singleton class of Bar (Bar::<Bar>). Therefore, the var reference
    # is accessing `Bar::<Bar>#@var`
    @var
  end
end

Implementation

There are two main parts to fix, which can be found in the first commit:

1. Started using a new object to represent the surrounding method definition in node context, which includes the receiver
2. Stopped pushing def self.foo as a singleton entry in the node context nesting. Method receivers don't advance the lexical scope and do not influence constant resolution. They only influence the type of self

Then I made the necessary adjustments on the type inferrer.

Automated Tests

The last commit includes a bunch of tests verifying that we're correctly handling these cases in definition and hover.

[Morriar]

Should we add a few tests using extend?

[vinistock]

There's no logic in go to definition that's specific to extend and I've been trying to not mix Rubydex related tests with the request related tests.

For example, we already have tests to assert that we follow ancestors when searching for instance variable definitions. If that wasn't working for extend, that would be a bug in Rubydex and so I believe the test belongs there.

[Morriar]

Does this mean we'll handle cases like def foo.bar; baz; end as if it didn't have a receiver?

[vinistock]

Yup. It's not correct, but I didn't think it was worth the complexity to add a special case to represent an unknown type of self.

Method definition receivers other than self are already not super common and dynamic ones are even more rare.