Added methods to define default sort and limiter fields.

My first ever pull request!

OK, so with this pull, we can define default sorts and field limiters with defaultSortInfo() and defaultFieldInfo().  If the client passes a query string in the URL, they are completely overridden.

One thing I tried to do was to add the processing methods to check for invalid stuff, and allow you to supply the defaults in the same way as you specify them in the URL; e.g. instead of DESC/ASC you can simply supply 'fieldname' or '-fieldname'.

Field filters (as opposed to field limiters) seem to be more complicated, so I've leaving them for now.

So... how does it look?


These methods handle invalid values that could be supplied in the defaultXInfo methods, which I've thought of a couple ways to deal with:

1. provide simplified copies of the parseRequest methods as processX methods.  Then, the data provider classes would need to call processX methods in addition to parseRequestForX methods.
2. change the name of parseRequestForX methods and modify them to merge values from both the request and the defaultXInfo methods.  The data provider classes would need to call the method by its new name.
3. Don't handle invalid values supplied via the plugin definition at all; let them hit the sorting/limiting logic and throw an exception there.  The data provider classes would call the defaultXInfo() methods directly.

I was leaning towards options 1 or 3, but I decided to try option 1, because I felt that having the processX methods was more consistent with the existing pattern of calling parseRequestForX in the data provider, and then having parseRequest sanitize the options.

On the other hand, I can see where it's not technically necessary to have this consistency, since the plugin-supplied options are being supplied by the plugin developer him/herself, and not by an API consumer.

So, should I go ahead with option 3?