Add ability to linearize ancestors

[vinistock]

Motivation

Step towards #1333

Add the ability to linearize ancestors for a given name.

Implementation

1. Changed the way we remember included, prepend and extended modules. We were throwing everything in separate arrays, but in reality we need to remember the exact order between prepends and includes to ensure we linearize it the right way
2. Added the linearization algorithm

The algorithm works like this:

class Foo < Bar
  include A
  prepend B
end

1. Start with the namespace itself [Foo]
2. Handle the include. We must linearize the ancestors of A and ensure we're removing any duplicate modules that have already been prepended or included
3. Then handle the prepend. We must linearize the ancestors of B and only remove duplicates if they are present in the prepended modules. It is allowed to have duplicates if the module was included

Looking at the tests will better clarify the edge cases.

Automated Tests

Added a bunch of tests and tried to cover all corner cases I could think of. Please let me know if you can think of other cases.

[andyw8]

🎉

[st0012]

Does it make sense to have foo.ancestor_names?

[vinistock]

Unless we discover a use case for the list of unresolved and unlinearized ancestors, I would vote against adding an API for that. It could potentially give the wrong impression to users of the index that the list is the linearized list of ancestors, which it isn't.

[vinistock]

Add a mixin_operations_module_names.

[Morriar]

Let's go with this approach for now but I think we'll need a graph instead to be able to implement requests such as Type Hierarchy Subtypes. Maybe something like a poset.

[vinistock]

I guess the trade off here will also involve performance. If building the poset takes longer and requires more memory, then it could potentially not be worth it (since we use linearization all the time for go to definition, hover and completion).

Even if it's the more correct implementation, it might be better to pay a higher price and search for subtypes only when someone is requesting it (which not as common as the other features).

[vinistock]

@st0012 raised a great point of circular dependencies involving aliases. Will add a test for the following

module A
end

ALIAS = A

module A
  include ALIAS
end