Large number of style-related changes to pass pylint

This is not to be merged, but should be reviewed and scrutinized. /cc @silvolu @tseaver

This is upstream of #235 as that was motivated by this larger effort towards fixing #179 and #178.

As for review, we should particularly discuss the things I pointed out.

Some key things to notice:
- The tools (`pep8` / `pylint`) disagree about continutation lines.
  This is because [PEP8][1] is ambiguous about "multi-line constructs".
  One of the examples for bracket indentation in the PEP is

  ```python
  my_list = [
      1, 2, 3,
      4, 5, 6,
      ]
  ```

  but the PEP doesn't explicity say whether or not

  ```python
  my_list = [1, 2, 3,
             4, 5, 6,
             ]
  ```

  would be allowed. As it turns out, `pep8` (the tool) considers
  the latter to be a continuation while `pylint` does not.
- I changed all indentation where this was a problem, but was
  intentionally inconsistent. This way we can see "all options"
  and discuss whichever is preferred.
- I made a `_MetadataMixin` helper class for methods shared between
  `storage.Bucket` and `storage.Key`. I did not refactor the affected
  tests but they do still give 100% coverage.
- To silence docstrings warnings I added many bogus docstrings
  without actually documenting the given objects.
- I factored out part of

  ```python
  storage.connection.Connection.generate_signed_url
  ```

  into a `_get_expiration_seconds()` method and added tests.
  This method is untested (has `# pragma NO COVER`) and is still very long.
  I refactored because `pylint` complained about too many locals.
- I made sure `tox -e lint` and `tox -e cover` passed.
- I increased the maximum number of arguments from 5 to 10 and
  the maximum public methods from 20 to 30. Offenders were:

    - `storage.connection.Connection.make_request` (6 arguments)
    - `storage.connection.Connection.api_request` (9 arguments)
    - `storage.connection.Connection.generate_signed_url` (6 arguments)
    - `storage.bucket.Bucket` (27 public methods) and
    - `storage.key.Key` (23 public methods)

  I think refactoring these should be considered (though is not
  mandatory). I certainly don't know a good solution for the class
  public methods.

[1]: http://legacy.python.org/dev/peps/pep-0008/
As long as we don't for get it, sure.  In some ways, that whole refactoring would be better in a separate PR.