Properly implement document/documentSymbol

[milesziemer]

When I re-wrote the language feature implementations in #166, I
refactored documentSymbol. But it mostly just copied the previous
implementation, which produced a flat list of symbols. This meant that
member symbols would appear at the top-level, but documentSymbol is
meant to provide a tree-like view, where symbols can have children. So
this commit re-writes documentSymbol to produce a list of only the
top-level shapes' symbols (and the namespace statement's symbol), with
members' symbols being added as children to the top-level symbols, and
members of inline i/o are children of the inline i/o symbol.

I also changed up the Symbol kind a bit, so root shapes are of type
Class (except enum/intEnum, which are of type Enum), members are
of type Field (except enum/intEnum members, which are of type
EnumMember), and service/resource/operation members are of type
Property.

I explored having different symbol kinds for different types of shapes,
like making service-type shapes be of kind Interface, and primitive
types being of their corresponding kind (for example, an integer shape
would have kind Number), but I wasn't sure what some shape types
should be. For example, what should a blob shape be? So I decided to
just make all top-level shapes just be of kind Class.

I also fixed the range and selection range of symbols. Range now covers
everything from shape type -> end of block (if applicable), and
selection range is just the shape/member name.

I considered adding more children for service-type shape members,
like making the operations child symbol of a service shape have a
child for each of the operations in the list, but I think it would make
the tree view more noisy, plus I think the intent is to show symbol
definitions.

I also made a minor adjustment to the parsing of operations members,
making them always be inline or node member defs, instead of possibly a
regular member def for non-inline i/o. This is consistent with
resource/service members, which are always node members.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.