Draft of feature encoding changes

As discussed on the call this morning I've made a draft of some changes to
how we encode the feature tag set included in the request. The PR can be
found here: https://github.com/w3c/IFT/pull/149

Note, there are a couple deviations from what we discussed:

   1. We talked about switching to referencing the ISO OFF specification
   instead of Microsoft's OpenType spec. However, it appears that ISO OFF
   isn't publicly available. So I can't easily link to it from the IFT
   specification. Given that, I think it's more useful for implementers to
   continue to link to the public OpenType one instead.
   2. After thinking about the process of how we could actually add entries
   to the list after the initial publication I've decided we'll need some
   versioning mechanism to accomplish future updates since the client and
   server must be speaking the same encoding. For now since there is only one
   version, I haven't actually introduced the mechanism yet, but I did note in
   the appendix that the current list is version 1 and future updates may
   introduce a new version plus a mechanism to communicate it (likely a new
   field in client state and request).
   3. One thing that I forgot to mention during the call which is important
   is that the sorted integer list is delta encoded. That means we encode the
   delta between an entry in the list and the previous entry instead of the
   absolute value. This means generally most entries should encode in one byte
   even if we have IDs that are greater than 127. I made one small change to
   help here and moved the ss01-ss20 and cv01-cv99 encodings to the end of ID
   space so they don't add large gaps between other unrelated feature tags.
   With that change everything other than those two groups now have ID's less
   than 127 which guarantees they will encode in one byte.