Extend ImportCompletion with declarationType

[i-am-the-slime]

Description of the change

This change extends the Completion datatype in the IDE. More specifically, it adds declarationType as a field to import completions. This type represents what type of declaration (value, type, typeclass, operator, type operator, etc.) the IDE will add to the file if applied.

This addresses #3083 which currently prevents users from importing identifiers if there is more than one candidate with the same name in a file (for example the type-level /\ and the value level /\ from Data.Tuple.Nested). Today, attempting to import /\ causes psc-ide to throw an exception.
It's already possible to refine the import command with a namespace filter to make the import succeed, however users (and clients) currently lack the necessary information to make a decision about the namespace. This PR adds this information.

You can also read a longer background story

---

Checklist:

• Added the change to the changelog's "Unreleased" section with a reference to this PR (e.g. "- Made a change (#0000)")
• Linked any existing issues or proposals that this pull request should close
• Updated or added relevant documentation
• Added a test for the contribution

[kritzcreek]

This is probably my favourite PR I've gotten so far :) Thank you for the detailed write-up.

I don't think it's a big deal, but we might want to think about how before this PR it doesn't matter if you pick the type or data constructor completion for a newtype, because you'll always get the import that includes the constructor. Once we merge this users will get the choice which is nice, but it also means they have to think about which of the two completions to pick. You can always automatically fix the compiler warning if you didn't need the constructor, but failing to import it when you need it produces a compiler error, that requires more thinking than just applying a suggestion.

Code-wise you can use the DeclarationType from here, instead of re-creating it:

purescript/src/Language/PureScript/Ide/Filter/Declaration.hs

Lines 13 to 22 in 7ecc426

	data DeclarationType
	= Value
	| Type
	| Synonym
	| DataConstructor
	| TypeClass
	| ValueOperator
	| TypeOperator
	| Module
	deriving (Show, Eq, Ord)

That way the clients could also just use that field and plug it directly into a declaration type filter, rather than moving back and forth between namespaces and declaration types: https://github.com/purescript/purescript/blob/7ecc42669c69682996f2196ba2eef6c4ca827348/psc-ide/PROTOCOL.md#declaration-type-filter

Also thanks for the note about how the ide servers "Can't parse your command" errors aren't helpful when you're hacking on it, I know how to fix that problem but just forgot about doing it.

[i-am-the-slime]

Thanks for the praise for the PR, it makes me very happy!

I changed the code to use the existing declaration type. It's much simpler that way!

Concerning potential confusion for imports, I completely agree with you that there's no need to confuse users when there's really one good option of imports for an identifier. However, since we have these edge cases I prefer exposing this right away here, and then deciding how to present the right information to the user in the language server.

Something along the lines of: If there are duplicates where not specifying a type declaration filter will lead to an exception we add the information to the import label. Otherwise, we could merge multiple non-conflicting suggestions into just the one for the Identifier(..).

Having said that, we could use the same logic that we use for always importing Identifier(..) instead of Identifier to simply import both (/\), type (/\) and then remove unused imports (I guess the chance that a user might want both is high anyway). Somehow I feel it'd be better to allow the LS to make these decisions and keep psc-ide as dumb and literal as possible.

[kritzcreek]

Just one more nit, thanks again, this looks great!