Add symbol tags as proposed for LSP specification (e.g. visibility tags, static, abstract, etc.)

[travkin79]

Adds new symbol tags as proposed in my PR on the LSP specification, for example, adding private, package, protected, and public visibility tags as well as tags like static, final, abstract, read-only, nullable and non-null. Our motivation comes from our wish to add visibility and other symbol details to the outline view (see discussion eclipse-lsp4e/lsp4e#977), but maybe also to the call hierarchy and to the type hierarchy or to other related features / LSP operations.

The PR on the LSP specification requires at least one implementation in a language server and / or a client. We plan to finish a [first language server implementation in clangd](microsoft/language-server-protocol#2003
and llvm/llvm-project#113669) and a first client implementation in LSP4J, LSP4E, and CDT LSP (which is using clangd).

See microsoft/language-server-protocol#2003
and llvm/llvm-project#113669
and eclipse-lsp4e/lsp4e#1149

[jonahgraham]

@travkin79 your use case is compelling. AFAIK LSP4J hasn't been the first implementation for an LSP feature before. LSP4J has had pre-released features though. It sounds like we have a bit of a chicken-and-egg situation here, and I don't want LSP4J to be what prevents moving us forward.

For pre-release we marked all elements that were not in the official spec with @Beta (com.google.common.annotations.Beta). Lets do that here too and then we can move towards a release with this change in it.

Nothing in the current HEAD has @Beta - but see an old example part of #133 if you want a reference:

lsp4j/org.eclipse.lsp4j/src/main/java/org/eclipse/lsp4j/Protocol.xtend

Line 1938 in 74e8804

@Beta

Having the @Beta means we can change around those items easier without as much consideration for API consumers of LSP4J.

[travkin79]

Hi @jonahgraham,
Thank you for the hint to the @Beta annotations. I think, I've seen them already somewhere. I'll add them and I think, they are very helpful for explicitly documenting API that is likely to change in near future.

Concerning the chicken-and-egg situation: I think, for getting my LSP specification proposal accepted, we need the following steps in the following order.

1. finish the first clangd language server implementation using the new symbol tags ([clangd] Support symbolTags for document symbol llvm/llvm-project#113669)
2. finish first language server client implementation that uses the new symbol tags
   i. Extend LSP4J to support the new symbol tags (Add symbol tags as proposed for LSP specification (e.g. visibility tags, static, abstract, etc.) #856)
   ii. Extend LSP4E to use the new symbol tags, e.g. in the outline view (Add symbol tags as proposed for LSP specification (e.g. visibility tags, static, abstract, etc.) #977 eclipse-lsp4e/lsp4e#1149 and Outline view icons are missing visibility / token modifier details - How can we change that? eclipse-lsp4e/lsp4e#977)
3. Hope for the LSP specification PR to be accepted ([#98] Add SymbolTag values for access modifiers and other modifiers microsoft/language-server-protocol#2003)