DEV: Refactor checkpoint logic out of FileContentsManager into a separate class.

The purpose of this change is to provide an API for users to replace just the checkpointing behavior of a ContentsManager.  This is achieved by delegating checkpoint management to a dedicated `CheckpointManager`.

 The impetus for this change came after I completed a full Contents API implementation in [pgcontents](https://github.com/quantopian/pgcontents) and realized that in many cases I actually wanted the files managed by my ContentsManager to be present in the filesystem.  (This was most notably true when uploading data files.)  After playing around with alternatives for a while, I realized that the "Checkpoints API" can be implemented independently of the rest of the Contents API.  This is valuable because it makes it possible to separate the storage backend for the current working version of a file from the storage of previous versions.  This significantly lowers the barrier to entry for doing remote storage of checkpoints as well as things like managing checkpoints through version control.

**Changes:**

- Add a `CheckpointManager` base class and infrastructure for creating a
  `checkpoint_manager` instance attribute on `ContentsManager`.

- Provide default implementations of `delete` and `rename` in the base
  `ContentsManager` class.  **`ContentsManager` subclasses are now
  required to implement `delete_file` and `rename_file`.**  These methods
  no longer need to manage checkpoints.

- Move checkpoint-related functionality from `FileContentsManager` to a
  dedicated `FileCheckpointManager` subclass.

- Move shared filesystem interaction logic into `FileManagerMixin`
  used by both `FileContentsManager` and `FileCheckpointManager`.

- Minor tweaks to ContentsManager tests to get methods from the right
  object.