Document the use of reserved & unreserved characters in DRS IDs (#271)

* updating the badge to point to master

* Updated doc to make sure reserved characters are url-encoded

Doc Fixes:
* DRS IDs are strings made up of uppercase and lowercase letters, decimal digits, hypen, period, underscore and tilde [A-Za-z0-9.-_~]. See https://tools.ietf.org/html/rfc3986#section-2.3[RFC 3986 § 2.3].
* All RFC 3986 § 3986 reserved characters including whitespace in DRS IDs must be url-encoded [!*'();:@&=+$,/?#[] ]. See https://tools.ietf.org/html/rfc3986#section-2.2[RFC 3986 § 2.2].

* Making DRS ID reserved chars stricter

* Undo README.md update

* Added text to allow custom encoding

All reserved characters including whitespace [!*'();:%@&=+$,/?#[] ] in DRS IDs must be may be custom encoded only using unreserved characters [A-Za-z0-9.-_~]. Note: DO NOT expect this custom encoding to be supported by other DRS implementors.

* clarify guidance for non-standard internal IDs 

@susheel -- I went to fix a small typo ("must be may be"), and ended up proposing this simplified wording. My intent was to make it clear this is not an official part of the API, and most readers can ignore it; it's just useful guidance to server developers on how to be compliant.

* fix build problem (by adding dist: trusty)

docs/asciidoc/front_matter.adoc

@@ -10,7 +10,8 @@ The primary functionality of DRS is to map a logical ID to a means for physicall
 
 Each implementation of DRS can choose its own id scheme, as long as it follows these guidelines:
 
-* DRS IDs are URL-safe text strings made up of alphanumeric characters and any of [.-_/]
+* DRS IDs are strings made up of uppercase and lowercase letters, decimal digits, hypen, period, underscore and tilde [A-Za-z0-9.-_~]. See https://tools.ietf.org/html/rfc3986#section-2.3[RFC 3986 § 2.3].
+* Note to server implementors: internal IDs can contain other characters, but they MUST be encoded into valid DRS IDs whenever exposed by the API.   
 * One DRS ID MUST always return the same object data (or, in the case of a collection, the same set of objects). This constraint aids with reproducibility.
 * DRS v1 does NOT support semantics around multiple versions of an object. (For example, there’s no notion of “get latest version” or “list all versions”.) Individual implementation MAY choose an ID scheme that includes version hints.
 * DRS implementations MAY have more than one ID that maps to the same object.