Fixed precision proj strings

As determined in #426, using the default precision for converting floats to strings in the Proj4 initialiser ends up differently in Python 2 vs 3. This causes subtle difference in the resulting conversions. With @pelson's comment, I've changed this to 17 decimal places for both.

Note, I don't have any way to cross-validate that these are correct, except that they match between Python 2 and 3.

I know GitHub has an image diff, but most of the changes are pretty small, so I've added the image diffs here:
 * barbs_regrid ![result-barbs_regrid-failed-diff](https://cloud.githubusercontent.com/assets/302469/4601417/d8301248-50fc-11e4-8d8d-94e639982298.png)
 * barbs_regrid_with_extent ![result-barbs_regrid_with_extent-failed-diff](https://cloud.githubusercontent.com/assets/302469/4601404/67dadeb0-50fc-11e4-8852-d182809c5e7c.png)
 * contour_with_interiors ![result-contour_with_interiors-failed-diff](https://cloud.githubusercontent.com/assets/302469/4601405/6f16d6b6-50fc-11e4-9e05-c9f08049e1f3.png)
 * gridliner1 ![result-gridliner1-failed-diff](https://cloud.githubusercontent.com/assets/302469/4601406/7821b3c0-50fc-11e4-9402-e55cb9baf5ee.png)
 * pcolormesh_global_wrap1 ![result-pcolormesh_global_wrap1-failed-diff](https://cloud.githubusercontent.com/assets/302469/4601407/803b0886-50fc-11e4-9ca0-33ba0eb272f4.png)
 * pcolormesh_goode_wrap ![result-pcolormesh_goode_wrap-failed-diff](https://cloud.githubusercontent.com/assets/302469/4601408/878ed176-50fc-11e4-87d7-8652cfdf39d7.png)
 * quiver_regrid ![result-quiver_regrid-failed-diff](https://cloud.githubusercontent.com/assets/302469/4601410/b07b7eae-50fc-11e4-82d9-47b1dcc0fa58.png)
 * quiver_regrid_with_extent ![result-quiver_regrid_with_extent-failed-diff](https://cloud.githubusercontent.com/assets/302469/4601412/b902e198-50fc-11e4-87e4-2dffe123b32b.png)
 * streamplot: ![result-streamplot-failed-diff](https://cloud.githubusercontent.com/assets/302469/4601416/cfe347b8-50fc-11e4-8677-1df11994889e.png)

Well, since doubles are good to [about 16 digits](http://en.wikipedia.org/wiki/Floating_point#Internal_representation), maybe that's good enough?

A few random examples:
```
$ python -c "print('{:.17}'.format(1.63))" 
1.6299999999999999

$ python -c "print('{:.16}'.format(1.63))" 
1.63

$ python -c "print('{:.16}'.format(100000000000.63))" 
100000000000.63

$ python3 -c "print('{:.16}'.format(100000000000.63))" 
100000000000.63

$ python3 -c "print('{:.16}'.format(1.63))" 
1.63

$ python3 -c "print('{:.16}'.format(1.633))" 
1.633
```
though with floating-point, I'm sure you can come up with something that will be ugly at some point...