resolve #155 - fix hash key ordering bugs in rearrange

bump version, document Changes, add some missing tests to the MANIFEST

Squashed commit of the following:

commit a68157bb6184d57676e63c7929879a285c3b6acb
Author: Lee Johnson <lee@givengain.ch>
Date:   Tue Nov 25 21:52:33 2014 +0100

    sort keys in the _rearrange_params method

    and favour certain keys other others when a param can have several
    options. for example:

    	[ 'BAR','FOO','BAZ' ]

    will be sorted alphabetically, but should we want to 'FOO' to always
    be favoured over any other option if it is provided then we need to
    add it to the regexp in the sort of the keys so when a user passes
    in:

    	-foo => 1
    	-baz => 2
    	-bar => 3

    then -foo will be taken as the canonical option, but if -foo is not
    passed in then we sort the options alphabetically meaning the -bar
    option would be taken

    this is relevant for the [ 'TYPE','CONTENT_TYPE','CONTENT-TYPE' ]
    set of params as passing through both -type and -content-type and
    additionally -charset leads to hash key ordering bugs meaning the
    Content-Type output in header is inconsistent. ref: GH #155

commit 18a10cbd09140e8a233f9543ef901d52579a5974
Author: Lee Johnson <lee@givengain.ch>
Date:   Tue Nov 25 15:17:00 2014 +0100

    failing test case(s) for #155 - rearrange hash key ordering bugs

    if i push this branch out it should fail on the travis CA server,
    lets see if that happens...

    it would seem there are still hash key ordering bugs when it comes
    to calling the rearrange function in CGI::Util as passing a hash
    through to the header method, with all three possible arguments for
    the content type:

    	'-charset' => 'UTF-8',
    	'-type' => 'text/html',
    	'-content-type' => 'text/html; charset=iso-8859-1',

    shows an inconsistent output for the Content-Type header. ideally
    you shouldn't do that, but when you do *we* should be consistent in
    what we output.

    TODO: fix and squash merge