Fix HmacAuthV4Handler to treat POST parameters properly.

I ran into this problem when digging into why AWS was returning HTTP 505 Version Not Supported
responses for autoscaling's CreateLaunchConfiguration action.  In past cases it looks like this
error has occurred when the query string of GET requests exceed some threshold (AWS likely reads a
fixed size and takes the last 5 bytes on the first line as the HTTP version).  Although the
AWSQueryConnection.get_object call was set to use POST the actual request consisted of a POST with
all of the parameters in the query string.

In researching this I figured out the logic to actually map request parameters into the query string
(GET requests) or into the request body (POST requests) actually occurs in the add_auth call in
_mexe shortly before the request is issued to Amazon.  For HmacAuthV4Handler there was no special
POST request handling so parameters always came in as query strings with the method 'POST'.

This patch does the following:

    (1) Moves the query string / request body manipulation on HmacAuthV4Handler to before the
canonical_request is calculated so that the request body signature is correctly generated.

    (2) Updates the canonical_uri to look at req.auth_path instead of req.path.  Since the query
string manipulation is occuring before the request is signed now we need to use the cached version
of this field that is set aside for authentication already.

    (3) Modify canonical_query_string to return '' when a POST request is used.  This is because the
parameters in a POST request will now be part of the body when calculating the canonical_request to
sign.

This appears to do the right thing in the cases I've tested.  It does blow away the contents of
request.body when their is a query string present so if anything ever attempts to make a POST call
with both params and data set bad things could happen.  This is just copying the behaviour already
present in QuerySignatureHelper when a POST request is processed.
Fix typo in docstring for AutoScaleGroup object.
Add __future__ import of with_statement for python2.5 (inc. Jython) compatibility.
Merge pull request #1085 from staer/with-statement

Add __future__ import of with_statement for < python2.5 compat
Support multiple DBSecurityGroups for DBInstance.  Fixes #1086.
pep8 cleanup, fix long line lengths
Add vgw route prop and static route API to VPC client
Merge branch 'vpc-bgp-noroute' into develop
Add crc32 validation to dynamodb responses
Add support for dynamodb batch get consistent reads
Merge branch 'dynamodb-cbget' into develop
Fix multipart uploads too big for default part size

The default part size of 4 MB is too small for any files over 40,000 MB, and there's no checking to ensure that a part size passed in is big enough.

I added a check to make sure the default part size is big enough. If it's not, the minimum part size needed is found and then it figures what what the smallest part size allowed by Amazon's API is and uses that instead.
Add failing integration test for sigv4 failure

This repros #1037.
Merge branch 'g2harris-develop' into develop
Support unicode for building single list params

As mentioned in #1066, some of the responses return
unicode, and it makes it tricky to feed the return
values into subsequent calls.

The integration/unittests all pass for me
Merge branch 'develop' of git://github.com/boto/boto into multipart_size_fix
Merge branch 'develop' of github.com:boto/boto into develop
Fixing docstring for create_snapshot method.  Fixes #1101.
Move part size calculation to a separate module

I intend to use this for the concurrent multipart uploads
as well.  I've added some unittests, and fixed a few issues
in the original minimum_part_size calculations.
Starting power should be 3 not 2 for part size

As pointed out by @khagler, given the default part size for
glacier multi part uploads is 4MB, the part size it tries should be 8MB
or 2 ^ 3.