Track method's visibility during indexing

[st0012]

Motivation

Closes #1941

Implementation

• Adding a visibility field to the Member entry, which is a superclass of Accessor, Method, and Alias.
• In the DeclarationListener, create a nested stack structure to track the visibility of the current scope.

Nested stack

Every namespace will have its own visibility stack, for example:

class Foo
  class Bar
  end
end

# [[<top-level visibility stack>], [<Foo visibility stack>], [<Foo::Bar visibility stack>]]

And at each level (scope), we simply push new visibility to its stack whenever we see a modifier.

 # [[:public]]

def foo; end # :public

private # [[:public, :private]]

def bar; end # :private

protected # [[:public, :private, :protected]]

def baz; end :protected

The only exception is when we face private def foo; end, which will pop the stack when we leave the declaration.

I chose a different data structure than test CodeLens's because it assumes methods are always inside a class, which would create a problem here. And I also feel the way it swaps visibilities is harder to understand than the nested stack I use here.

One drawback of this design is that if one scope level has many visibility modifiers, it'd create a big visibility stack at that level, like:

private
private
private
# repeat 997 more times, then we'd have [[:private * 1000]]

However, I think it's an edge case that we can ignore in order to get a simpler implementation.

Automated Tests

I added 2 new test cases for this change.

Manual Tests

[vinistock]

If visibility is already set on the parent, we don't have to set it here.

[st0012]

@vinistock I've changed the way visibility is set on entries and reduced the amount of changes needed.

[vinistock]

I agree with Alex. I would reduce the indirection in favour of more direct code.

[Morriar]

This is great! 🎉