Fix bug with error handling

See #46

Fix `xhr` module interface and allow for xhr retries

Upgrading xhr to 2.0.0 broke the interface in the previous version. Fixed now.

Retry logic was never being called. Fixed now.

Updated xhr module to 2.0.0

• xhr v2.0.0 adds ie8 support

Lodash

We now depend of lodash proper instead of all the lodash micro-libraries.

Remove unused `crumb`

• Crumb was a special case used internally and so has been removed from code
• Documentation updated to show how to do CSRF protection generically

Dependency Updates

v0.4.1

0.4.1

`delete` everywhere

We had backwards compatibility for del method but for sanity's sake we removed all traces of it. So now users can only use delete methods on the client/server fetcher interface as well as the data-fetchers' interfaces.

Thanks @ptomasroos

Change `del` method to `delete`

We used del as the delete operation method but we have now standardized the name to delete. So now the CRUD (create, read, update, and delete) methods are all trivial to spell and use.

Feature: Custom http status codes support

Data-fetchers can specify an HTTP error statusCode (400, 404, etc) by tacking on a statusCode property to the error object passed into the callback. If the statusCode property exists on the error object, fetcher middleware will use that HTTP response code.

Data-fetchers can now pass a 3rd meta parameter to their CRUD callbacks. If meta.statusCode is set, then fetcher middleware will use that HTTP response code.

Thanks to @mtscout6 for noticing and implementing this in #22.

Bugfix: Better error handling

Fixed an issue where middleware didn't stop after throwing error. See #18 for more details.