Define Key-As-Segment URL convention for resource paths

Key-as-Segment uses the (primary) key of an entity type. Primitive types are represented in path key segments without "single quote decoration" or "double single quotes within" and use standard percent-encoding to map them into the lexical space of URL path segments. 4.01 Services that support key-as-segment syntax (for single-part keys only) should support the following precedence rules: Following an entity collection segment: i. Try to match an OData segment (starting with “$”) ii. Try to match an alias-qualified bound action name, bound function overload, or type name iii. Try to match a namespace-qualified bound action name, bound function overload, or type name iv. Try to match an unqualified bound action name, bound function overload, or type name in a default namespace v. Treat as a key Notes: 1. For maximum interoperability, services SHOULD also support parens format, to avoid ambiguity, and to support multi-part keys. Note that, if they do not support the parens format, they must (continue to) include the @odata.id, @odata.editlink, or @odata.readlink, as appropriate. 2. The syntax of ContextUrl always uses parens syntax 3. Forward slashes in key values must be percent-encoded 4. Single quotes within key values do not need to be percent-encoded or doubled Example 3 with key-as-segment syntax and current syntax single quote can be literal within string or percent-encoded and isn't doubled (using ~/ as a shortcut for the service root) ~/People/O'Neil ~/People/O%27Neil ~/People('O''Neil') ~/People(%27O%27%27Neil%27) ~/People%28%27O%27%27Neil%27%29 Forward-slash within string must be percent-encoded just as in paren syntax ~/Categories/Smartphone%2FTablet ~/Categories('Smartphone%2FTablet')