Make it easier to mark a field as readonly

[ethanresnick]

I see two meaningful types of readonly fields:

1. "final" fields, which are fields that, once they're set (on the initial POST), are then unmodifiable (i.e. on PATCH). An example might be a username: settable to anything at first, but then not mutable.
2. "server-managed" fields, which are fields that are utterly unsettable through the API (i.e. on POST or PATCH), even on initial creation. This is stuff like: created-date, modified-date, and id (when server-generated ids are in use).

Right now, if the user wants one of their API fields to be readonly, whether final or server-managed, they have to manually add logic in the beforeSave transform in the resource description, to 403 if the client attempts to change one of these readonly fields. (For the final case, they even have to inspect the request to check the method.)

But this use case is common enough that there should be a declarative solution. That is, the user should be able to simple set a "server-managed" or "final" key to true in the resource description somewhere, and then a transform would automatically be added to handle the validation.

One natural place to put this key would be in the validation key that exists under each field in the info section. My issue with putting it here, though, is that it's not intuitive that values under info could actually affect the behavior of the app. So, instead, I'm thinking that resource type descriptions could get a "behaviors" key, structured like so:

{
  "behaviors": {
    "fields": {
      "created-at": {
        "server-managed": true
      }
  }
}

Adding this info under behaviors would then also need to be taken into account by the DocumentationController, to add it to the auto-generated docs.