[SwiftLexicalLookup][GSoC] New lookup method signature and Identifier initializer changes

[MAJKFL]

This PR includes changes suggested by @ahoppen under #2748 that didn't make it before merging.

[ahoppen]

Thanks for addressing my review comments. I think the following comments from #2748 are still open.

• [SwiftLexicalLookup][GSoC] Add proper guard scope and implicit name lookup #2748 (comment)
• [SwiftLexicalLookup][GSoC] Add proper guard scope and implicit name lookup #2748 (comment)
• [SwiftLexicalLookup][GSoC] Add proper guard scope and implicit name lookup #2748 (comment)
• [SwiftLexicalLookup][GSoC] Add proper guard scope and implicit name lookup #2748 (comment)

[MAJKFL]

1. I removed LookupName.refersTo and renamed ScopeSyntax.checkName to ScopeSyntax.checkIdentifier for extra clarity.
2. As far as I understand, it's not used anywhere in the compiler right now. Though there's this weird top level code behavior in playgrounds I described here. To be honest, memberBlock configuration wouldn't be perfect either, as it doesn't extract names from guard. I think everything will become clearer once we start testing against the compiler and as for now I think I'd like to leave the implementation as is so we can later iterate on it.
3. I think I might not fully understand this one. I added a test case with your example here. As far as I understand the result should be empty, or am I missing something?
4. I wanted to provide extra flexibility for sequential scopes to be able to use any result kinds, but I see now it was probably superfluous. I added a new LookupResult.getResult static method that creates a result specific for the provided scope kind.

[ahoppen]

1. I removed LookupName.refersTo and renamed ScopeSyntax.checkName to ScopeSyntax.checkIdentifier for extra clarity.

Thanks 👍🏽

2. As far as I understand, it's not used anywhere in the compiler right now. Though there's this weird top level code behavior in playgrounds I described here. To be honest, memberBlock configuration wouldn't be perfect either, as it doesn't extract names from guard. I think everything will become clearer once we start testing against the compiler and as for now I think I'd like to leave the implementation as is so we can later iterate on it.

OK, just wanted to make sure we are aware of it and don’t carry around old cruft just because nobody knows what it might be used for 👍🏽

3. I think I might not fully understand this one. I added a test case with your example here. As far as I understand the result should be empty, or am I missing something?

Oh sorry, I missed that test case. Looks good.

4. I wanted to provide extra flexibility for sequential scopes to be able to use any result kinds, but I see now it was probably superfluous. I added a new LookupResult.getResult static method that creates a result specific for the provided scope kind.

That’s a good step. I still think that it’s worth exploring to unify the fromFileScope and fromScope cases.

[ahoppen]

@swift-ci Please test