add support for decorators to schema langauge

[ecordell]

Supports decorators of the forms:

@decoratorName
@decoratorName(opt1,opt2)
@decoratorName(opt1,(opt2a,opt2b))

This parses the decorators into the AST as a new edge type from the items they decorate (currently only supported within definition blocks, pending more discussion of how they will be used)

• [x] basic decorators
• [x] options
• [x] nested options
• [x] multiple decorators for the same statement
• [ ] strings or identifiers as option values

[alsbury]

We are looking for the ability to add basic metadata to schemas. Our use case is that we want to be able to add things like descriptions, categories, tags.

` @description('This would likely be a multi-line description describing the definition/relation/permission') definition user {}

@description('My description for application') definition application {

@category(['application','users']) @description('A description of the user admins relationship') relation user_admins: user | group#members

@category(['application','users']) @description('A description of the user readers relationship') relation user_readers: user | group#members

@description('A description for user write permission') permission user_write = user_admins

@description('A description for user read permission') permission user_read = user_write + user_readers

} ` At a minimum, we are looking for a way to pass key/values pairs related to an identifier from the schema.

[josephschorr]

@alsbury description should be put into doc comments like so:

    /**
     * reader indicates that the user is a reader on the document.
     */
    relation reader: user

[alsbury]

@josephschorr yeah, I can see how description may be best like that. I'm in the middle of sorting out how we will use the metadata. I do see us using a human readable label with a longer description as a possibility. That along with metadata for how to group data for UI's. Once our use case is better defined I might have more useful feedback.

[josephschorr]

@alsbury yeah, makes perfect sense. The reason we kept the comment data in the parsed protos was so that we could use the entered descriptions in generated code down the road