Fix ALLOW_OPTIONS

`Range.allow` is a field that describes the type of `allow` statements we want to print in that `Range`'s pool. The choices for this field are listed in ALLOW_OPTIONS. However, it does not currently cover all the combinations of `allow` statements we might want.

This was discussed in IRC, where I made an attempt to list the `allow` choices we might want.

> 15:38 < drkitty> I attempted to enumerate all the possible choices for allow statements. I came up with this: (1) neither VRFs nor Ctnrs (no hosts at all); (2) just VRFs; (3) just Ctnrs; (4) both VRFs and Ctnrs; (5) known-clients (a superset of 4); (6) any client at  all (a superset of 5).

We decided that choice 1 was not useful, and if that behavior was desired the `Range` should just be disabled.

Here are the choices that I implemented, with more details:

- `ALLOW_ANY`: Allow any client at all.
- `ALLOW_KNOWN`: Allow any "known" client. A client is "known" if it has a host declaration in any scope.
- `ALLOW_LEGACY`: Allow any client that is a member of this `Range` and also shares a `Ctnr` with this `Range`.
- `ALLOW_VRF`: Allow any client that is a member of this `Range`'s VRF.
- `ALLOW_LEGACY_AND_VRF`: Allow any client that would be allowed by `ALLOW_LEGACY` or `ALLOW_VRF`.

---

Note: I changed the `max_length` of the `allow` field, so **there is a schema migration**. Sorry about that. It just seemed that wasting 19 characters of the field was stupid. ***Everyone will also need to do a full Maintain migration after we merge this pull request***, because ranges in either of the VRFs `avaya-hack` or `ip-phones-hack` were not given the correct `allow` option.