so this loks like we're losing data. However here's why this is safe:

1. Only VB makes these ActionlessItem's
2. We literally do nothing when an ActionlessItem is clicked on. You can see that here:

   roslyn/src/EditorFeatures/VisualBasic/NavigationBar/VisualBasicEditorNavigationBarItemService.vb

   Lines 76 to 85 in e126f50

   	Protected Overrides Async Function NavigateToItemAsync(document As Document, item As WrappedNavigationBarItem, textView As ITextView, cancellationToken As CancellationToken) As Task
   	Dim underlying = item.UnderlyingItem
   	Dim generateCodeItem = TryCast(underlying, AbstractGenerateCodeItem)
   	Dim symbolItem = TryCast(underlying, SymbolItem)
   	If generateCodeItem IsNot Nothing Then
   	Await GenerateCodeForItemAsync(document, generateCodeItem, textView, cancellationToken).ConfigureAwait(False)
   	ElseIf symbolItem IsNot Nothing Then
   	Await NavigateToSymbolItemAsync(document, symbolItem, cancellationToken).ConfigureAwait(False)
   	End If

As we can, VB only supports doing something when a SymbolItem or AbstractGenerateCodeItem was the one selected. ActionlessItems are solely for having a hierarchy in the UI.

spans are now a thing only for symbol-items. no other items need that.

these values are added for LSP purposes. note that spans/selectionSpan will be refactored again in my next pr which unifies span handling. It will unify handling of both 'entire entity span' vs 'navigation span' as well as 'span to navigate to if in the starting document' vs 'span to navigate to in another document'.

NavigationSymbolId and NavigationSymbolIndex currently exist but will be removed in my followup PR. tools must not go back from tehse to symbols. instead, the service should accurately and uniquely define the behavior the consuming services need through simple data it passes back.