This adds support for moving posts to a collection. This change relies
on #13 so that we can create and delete collections during tests.

Couple notes:

- CollectPosts accepts a single struct rather than an alias and a list
  of structs. This makes it easy to add new optional parameters in the
  future.

- We're passing `[]*CollectPost` around rather than `*[]CollectPost`
  which is done in some of the existing APIs. The reasoning for this is:

  - Idiomatically, slices are passed by-value (`[]foo`) rather than
    by-pointer (`*[]foo`) because slices are already reference types.
    Plus they're really cheap to copy since they're just a triple:
    pointer, length, and capacity ([related blog post][1]). We need
    pointers to slices only when we're trying to modify the original
    slice reference and don't have the ability to return a slice, like
    with `json.Unmarshal` (see also [this post][2]).

  - If we're trying to reduce copying, `[]*foo` is better than `[]foo`
    because otherwise `foo` will be copied when manipulating or
    accessing entries in the slice (like ranging over it).

  Existing APIs were left as-is to avoid breaking them. I can switch to
  `*[]CollectPost` if you'd prefer that but `[]*CollectPost` is more
  idiomatic.

[1]: https://blog.golang.org/go-slices-usage-and-internals#TOC_4.
[2]: https://blog.golang.org/slices#TOC_5.

Resolves #4.

Rather than accepting a naked string, accept a DeleteCollectionParams
struct so that new optional parameters can be added in the future
without breaking the API.

This adds support for deleting collections.

Resolves #1.

This closes #3