Add opt-in HTTPMethodOverride functionality (ported from gorilla/handlers)

[I know you've had previous discussions on this topic](https://github.com/gorilla/mux/pull/57), but if you ***are*** interested (fair enough you might not be) in adding this functionality to gorilla/mux then this pull request implements HTTPMethodOverride (ported from gorilla/handlers) as a Router method in mux. It's completely opt-in so doesn't affect any existing code. The API is modelled after StrictSlash(), as a method on Router that defaults to false.

It adds: -

1. A new method, `*Router.HTTPMethodOverride(bool)`

2. When set to `true`, it checks POST requests for the `X-HTTP-Method-Override` header and/or the form key `_method`, if either are found (and the value matches one of `PUT`, `PATCH`, or `DELETE`) then `request.Method` is updated with that value. GET requests are not checked, neither are any other method values valid. (Same approach as gorilla/handlers)

3. When set to `false` (the default), behaviour is exactly the same as current gorilla/mux

4. New Test, `TestHTTPMethodOverride()` covers all the new functionality

5. Full documentation (matching existing gorilla/mux style)

(I also updated `old_test.go`)

Obviously it's totally up to you guys as to whether you think this functionality should be included in mux - but it's there if you want it. Speaking personally I added it since, as a newcomer to Go, I was surprised/confused that when I tried to use `.Methods("PUT")` and then `<input type="hidden" name="_method" value="put" />` in my HTML `form` it didn't work as expected, especially since standard browsers don't currently implement the PUT/PATCH/DELETE HTTP verbs. Implementing it as a purely opt-in feature was I thought the best strategy since it doesn't affect existing use of the library. Anyway, if you do feel it's a worthy/relevant addition to mux then you can merge it. If not, no worries. (and feel free to delete this PR). Thanks.