Feature/altered exceptions

This MR covers the changes we discussed at IDLE on Feb 23.

What I did

• Updated and corrected version numbering
• Moved the hard-coded default error message to a protected static var
• Set handle_api_method_exception() as the default exception handler
• Renamed the DF_REST_FatalityReport class to DF_REST_Exception

Implications

As we've had to give up on extending DF_Exceptions, should we consider defining a parent class for this one? Then when we get around to implementing others that we've discussed, e.g. DF_Model_Exception, it could be the parent for those as well.

Setup

None

How to test

• Code review.
• Throw some of these exceptions around and see what happens.
• Can be tested with the altered_exceptions branch of AFES:
  • Log in and attempt a donation. The donate_post endpoint will throw a DF_Rest_Exception.
  • There's no handling added at the front end for this, but check the API response and confirm it looks like this:

• Throw a base Exception (e.g. change the throw in that donate_post endpoint), and check that it is still caught, and that the default error message is used in the API response.

• In the class you're using that extends DF_REST_Controller, override the protected static variable that defineds the default error message, and confirm that that one comes through in the API response when throwing a base Exception. e.g. in the AFES branch:

class Fmsync extends DF_REST_Controller
{

	protected static $_error_response_message = 'You\'re on your own, mate.';