Trim cache length in cachePop, not just cachePush

This fixes a bug where the `pjax.defaults.maxCacheLength` setting was
being applied when navigating to new pages but not when users hit the
back or forward buttons.

Two symptoms of this were:
* Setting `maxCacheLength = 0` didn't completely disable caching;
  hitting the back button followed by the forward button would ask the
  server for the first page but read the second one from the cache. I
  think this is probably the bug that was discussed on issue #406.
* Regardless of what you set `maxCacheLength` to, the forward cache
  would continue growing as long as you kept hitting the back button.
Split up and simplify maxCacheLength tests

A few changes to make these tests less scary:
* Invert `navigationWasCached` var to `didHitServer`, which feels a
  little more intuitive.
* Split the back button and forward button cases into separate tests.
* Reduce the number of assertions per test.
* Replace some comments with assertion text.
* Reduce `maxCacheLength` in the back button and forward button tests
  from 2 to 1 so that each test requires fewer steps.
Document `$.pjax.reload` function

Closes #441 [ci skip]
Merge pull request #410 from brigade/trim-cache

Trim cache length in cachePop, not just cachePush
Don't break the back button when hard loading

- Add a test case for going back from error pages which don't have pjax,
  as described in issue #422

- When hard loading a url, set the back action to the page's url from
  before the request was made

Fixes #422