Replace symbol's containerName by containerPath

[mickaelistria]

Currently, it seems like the containerName in a SymbolInformation uses a convention to use . to separate the various segments. However, . is a valid character for many symbols, so resolving the containerName to a path in the hierarchy can be tricky.
Some complex example would be to have a JSon such as

{
  "a" : {
  	"b": {
  	  "c": "value1"
  	}
  },
  "a.b" : {
    "c": "value2"
  }
}

In which case the symbols for c both return a.b as containerName. A correct resolution to parent SymbolInformation requires looking at the positions.
An alternative would be to replace a containerName and the . convention by a containerPath, that would just be locating the parent as a list of symbols.

[dbaeumer]

@mickaelistria at least in VS Code we only use the container name for rendering purpose. If we want to transfer a tree then I think we should add a new request to get a symbol tree. Or do I misunderstand anything?

[mickaelistria]

I found that the symbols request do pass the range of the symbol, which allows to easily show a tree. So I have much less need for containerPath now. Closing this issue as range are working well and are "conceptually" much stronger.

[bruno-medeiros]

I found that the symbols request do pass the range of the symbol, which allows to easily show a tree. So I have much less need for containerPath now. Closing this issue as range are working well and are "conceptually" much stronger.

Hold on a second, is the location of the symbol mean to be the the range of the whole element, or just of the identifier? ie, for class Foo { } is the range of Foo just Foo or class Foo { }? If it's just the range of the identifier, you can't build a tree...

[bruno-medeiros]

Opened #132