Add code completion for chained value factories

[jbartok]

No description provided.

[h0tk3y]

💭 Given that with a big enough schema this might be an expensive operation, I would suggest finding a way to build the index once (or maybe precompute/memoize some parts of it) and invalidate it on schema changes.

For instance, some precomputed or memoized state could include:

• For each value type, all value factories of that type grouped by the container type.
• For each container type, the set of paths like layout.settingsDirectory starting from that type (along with the type of layout.settingsDirectory)

[jbartok]

I've addressed this, please take a look.

[h0tk3y]

💭 Currently, in addition to the top-level type, you can use the members of the nested containers. For instance, in

foo {
    bar { 
        baz = qux.quux()
    }
}

qux could be a member of:

• bar's receiver
• foo's receiver
• the top-level receiver

We should probably discuss if we want to keep it that way, but if we do, these nested receivers should also contribute the value factory groups to completion.

[jbartok]

As it works now, qux will be found regardless which of those receivers it's on and will be proposed as a potential value for properties with the same type as the return type of the quux() function.

I think the real problem we should think about is that qux.quux() will be proposed as a potential value for baz even if qux comes from a totally unrelated block, which is part of the top-level receiver, but is unrelated to foo (thus by extension unrelated to bar and baz too).

[jbartok]

Added a TODO.

[h0tk3y]

LGTM 👍