Avoid writing malformed PDBs when the positions are too large.

@dermen reported [here](https://github.com/rmcgibbo/mdtraj/issues/87) that the PDB parser  emits malformed data when the coordinates are large. The problem comes from [this](https://github.com/SimTk/openmm/blob/master/wrappers/python/simtk/openmm/app/pdbfile.py#L281) string formatting:

`ATOM  %5d %-4s %3s %s%4d    %8.3f%8.3f%8.3f  1.00  0.00" % (atomIndex%100000, atomName, resName, chainName, (resIndex+1)%10000, coords[0], coords[1], coords[2])`

Normally, this string formatting produces an output of length 66, e.g.

```
>>> len("ATOM  %5d %-4s %3s %s%4d    %8.3f%8.3f%8.3f  1.00  0.00" % (1,1,1,1,1,1,1,1))
66
```

But when one of the `coords` is too large, the fixed with `%8.3f` specifier silently overflows, and you get something like this.

```
>>> len("ATOM  %5d %-4s %3s %s%4d    %8.3f%8.3f%8.3f  1.00  0.00" % (1,1,1,1,1,1,1, 10000))
67
```
Then, the numbers are no longer in the columns that the PDB format expects them to be in, and you get a little chaos like this pdb file.

```
ATOM   1043  C   XXX A   1    5440.61133429.05918685.440  1.00  0.00
ATOM   1044  C   XXX A   1    5440.09433431.55618686.787  1.00  0.00
ATOM   1045  C   XXX A   1    5441.66133431.52118684.366  1.00  0.00
ATOM   1046  C   XXX A   1    5438.82833430.99318684.258  1.00  0.00
ATOM   1047  C   XXX A   1    5442.92733432.08418686.896  1.00  0.00
```

Also, what is the procedure in OpenMM for testing the application layer? Does OpenMM have the infrastructure for application layer (python) unit tests?