Allow beta in resource versioning

[ellensartorelli]

Describe your request
As demonstrated in the Standards, we can specify the version of a resource in Reslang: resource v2/ResourceFoo { … }.

We would like to be able to manage beta versions as resources as well while we iterate with customers. Therefore we would like to specify: resource v2beta1/ResourceFoo { ... }.

When we attempt this in Reslang, we receive a parsing error:

Reslang error:  Problem parsing file /app/reslang/specs/buyer-api-v2/segment.reslang: Expected "/*", "//", "v", [ \t\r\n], or [a-zA-Z] but "\"" found., location: 2, 10

Describe the value this feature would provide
Supporting beta resources will allow us to distinguish between the stability of various portions of our API so our customers are informed to make decisions about how to interact with certain functionality. For example, if we're testing an endpoint with a set of customers, we would like to note that it is beta so other customers don't build out significant workflows around the beta route with the expectation that we'll be supporting it for the long-term.

We want to iterate quickly with customer input but without conveying a misleading level of maturity and stability for various offerings.

[sirishalal]

@ellensartorelli is it possible to use v0 for all beta versions and released versions can have numbers 1 and above? Would this be a good workaround for this? Please let me know your thoughts.