Add support for `SymbolInformation.signature`

[olafurpg]

Test plan

[olafurpg]

Changes I'd like to make on the SemanticDB types:

• Remove Scope because we use symlinks in 99% of all cases, and there exists is a workaround for the <1% case (just emit a separate SymbolInformation). For repeated Scope we need to add dedicated message on a case-by-case basis. For example, it makes to add ParameterList
• Replace ConstantType with nested constant types. The additional layer of nesting is just annoying to work with. I prefer to have ConstantStringType, ConstantIntType, etc. even if it makes the Type enum bigger (which is not a problem)
• Still unsure, but I'm not 100% satisfied with the ad-hoc solution for primitive/built-in types (string,number,...). One one hand, I like reusing TypeRef with magic symbols because of simplicity. On the other hand, given most compilers have special encodings for primitives, maybe we should just add dedicated Type to represent them. One benefit of this approach is that you can write a generic helper function to detect string/number/int types across different languages without having to enumerate special string values.

[olafurpg]

• On a second thought, having separate Constant message allows code reuse between types and terms. It's especially desirable to add terms for annotation arguments.
• We should consider adding TypeSignature.value or something equivalent for basic type A = B signatures. The current lower/upper bound design is to support type A >: B in Scala, but we should not sacrifice ergonomics for the >99% use-case.

[mkondratek]

Hello Olaf 👋 I wanted to make use of the generated bindings and I found an issue:

export interface ChatHistory {
    [chatID: string]: TranscriptJSON
}

turns into

data class ChatHistory(
  val chatID: String? = null,
)

(and hence - I guess - TranscriptJSON is not being generated)