* route is /api/forums/:id (may be slug)
  * versioning is done via Accept header
  * views are built with jbuilder
  * authentication is done via session cookies (or whatever the
    host app is using)

Also abstracted some test code, in anticipation of including
both topics and posts.

Posts count only includes posts the current user is allowed to know
about.

The standard UI automatically creates a post when a topic is created,
but API-based UIs might not. Previously an error would be raised when
creating a topic with no post, and also when approving it.

Alternatively, if we want to require an initial post, we should
add a validation.

I ran into an issue where `/api/topics` was routed to
TopicsController#index with a `forum_id` of `"api"`. With this
change, `/api/` routes go to the API.

This is a temporary fix, as it creates other problems if someone
decides to start a forum called "API". We could add `api` to the
reserved words list for Friendly ID, but some installations may
already have an API forum. We could give the API routes a prefix that
can't be generated by Friendly ID's default generator (e.g., `@api`).
Or we could get rid of the prefix entirely, and just use the
`Accepts` header to determine whether a request is for the HTML UI
or the API.

This API controller inherits basic authorization and flow control from
the HTML UI controller, and overrides methods to return results via
JSON API. Alternatives include:

  1. Build all-new controllers for the API (as I started to do with
     forums), and remember to keep authorization and such in sync
     between the API and the HTML UI.
  2. Add API functionality directly to the HTML UI controllers,
     using `respond_to` and conditionals.

Still evaluating these options.

Tried to cover all of the MUSTs and some of the SHOULDs from the JSON
API spec.

Specific errors are just returned as text messages for now.

Most of the new controller code will be extracted to a mixin module.
Likewise, the spec code can be extracted to shared behaviors.

Also reworked TopicsController#find_topic so that (a) the API
subclass can override the "not found" behavior, and (b) the method
works as a `before_action` with slightly simpler code.

Also fixed an internal error when a post is submitted with no
attributes.

Also moved some PostsController action code into `before_filter`s so
that the API's own `before_filter`s get a chance to act.

We now have a general notion of how create, update, and show requests
behave, and can focus on the specifics of what data a successful
request returns.

Also made api/forums#show properly return 409 Forbidden.

This is the pattern we're using for the other controllers, to get
permissions checking and such.

Also removed unnecessary `respond_to` from `ForumsController#show`,
and wrote a test to confirm that it was unnecessary.

Handles the routine mechanics of rendering the right responses.

Also implemented helpers for rendering relationship JSON.

This reduces some code duplication, but as a result sends a little
more info than necessary in the included post. If this is a problem,
we can get around it by passing info to the partial about what
relationships to reference.

Relies on the existing permission controls in the parent controller.

Fixed routes conflict, and RSpec 3 deprecation warnings from the API
specs.

So the client can display a reasonable "last active" time for a
topic with no posts.

... by using the post partial instead of sending a subset of
attributes.

... by extracting a partial with attributes and has-one
relationships.

It's used as a proxy for "recent topics," so it makes sense to
include new topics, even if they haven't received any replies.