Add a `range` Base-level Constraint

[benhamill]

This adds a range base-level constraint for use inside the template tag.

The use case I'm thinking of is stuff like this:

<uber>
  <data rel="collection users" url="/users" template="#user_index_template" action="read">
    <data rel="item user" url="/users/8765" action="read">
      <data name="name">Ben</data>
      <!-- ... -->
    </data>
    <!-- ... -->
  </data>

  <template id="user_index_template">
    <data name="page">
      <data name="pattern">\d+</data>
    </data>

    <data name="per_page">
      <data name="range">1-100</data> <!-- The server will only ever return a maximum of 100 users per page. -->
    </data>

    <data name="sort_by">
      <data name="options">
        <data>name</name>
        <data>joined_at</name>
      </data>
    </data>
  </template>
</uber>

I didn't update the html file because when I tried to run asciidoc, there were more differences than just my chance, so I figured there were some configurations I didn't have or something. I've never used asciidoc before, so... Lemme know if you want me to do that.

Also, lemme know if this seems like... too much cruft without commensurate benefit at this early stage in the life of the spec.

[mamund]

@benhamill:

I think a "tool-able" range implementation for UBER would look like this:

<template>
  <data name="per_page">
    <data name="range">
      <data name="min">1</data>
      <data name="max">100</data>
    </data>
  </data>
<template>

BTW - I'm OK w/ exploring these constraints now even if all of them don't make it into the first draft. I think trying these out can expose any weaknesses in the basic design and help inform the process of both base-line and extensibility constraint implementation down the line.

As for the PR, if you like, create a new branch (constraint-proposals) and add a new document to the proposals folder. We can start to collect constraints there and work through them without causing problems for the main spec doc.