Adds webforms back into the app for offices/agencies that don't have one

This brings back our web form for FOIA requests. While it works, and a URL exists, for every agency and office in the system, a link will only be shown to the user if that agency or office doesn't have of their own. If they do, that's the link the landing page for an agency or office will use.

The form no longer supports agency/office-specific fields, so the `custom_fields` field is removed from `FOIARequest`, and the `agency_fields` logic is removed from form submission.

This is downstrea of #197, so uses the new `office_slug` field to identify whether a `FOIARequest` is on an agency or an office. A `FOIARequest` can be on an agency if just an `agency` field is present, or an office if `agency` and `office` fields are present. In all cases, they have to be valid or the request submission endpoint yields a 404.

This also copies the contact emails from the related `Agency` or `Office` onto the `FOIARequest` object itself, so that it won't change even if the referenced objects do. The Request should keep a snapshot of what it was when it was sent. In the future, we should probably copy even more fields onto the `FOIARequest` object. 

Similarly, I think in the future we should denormalize `Requester`, since we're not planning user accounts, and simply copy the user details onto each request. We're already just creating a new `Requester` each time, even for the same email, so it may as well be a JSONField on `FOIARequest` or something.

This includes a migration 14, as does @jackiekazil's PR in #203. Whichever one of these gets merged first, the other one will need to merge in the other's work and renumber the migrations. As #203 stands, it needs to be changed in the way I mentioned there before these two PRs can play nicely together.
This is annoyingly brittle, because `assign_offices` has to be run before a field is removed, so that the SQL query it uses isn't referencing about-to-be-removed fields.