Fix bug in _is_string

It took me a second to find out what was being done in openmm._is_string and why, but the except block also has to catch ``ValueError``.  In some of the code I wrote, I got the following error (only showing the end of the traceback):

      File "/home/swails/amber/bin/ParmedTools/simulations/openmm.py", line 492, in simulate
        simulation.context.setPositions(position_container.positions)
      File "/usr/local/openmm/dev/openmm/python2.7/simtk/openmm/openmm.py", line 3715, in setPositions
        try: args=stripUnits(args)
      File "/usr/local/openmm/dev/openmm/python2.7/simtk/openmm/openmm.py", line 1167, in stripUnits
        elif not _is_string(arg):
      File "/usr/local/openmm/dev/openmm/python2.7/simtk/openmm/openmm.py", line 1104, in _is_string
        if first_item == inner_item:
    ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

The problem here is that position_containers.positions is actually a NATOM-length tuple of Vec3 quantities.  Therefore, both first_item and inner_item resolve to valid python objects: a Vec3() and the first value from that Vec3(), respectively.  Attempting to compare the two results in the ValueError which passes through uncaught.

Perhaps ``_is_string`` should be replaced with just 

    # Python2 only; catches str, unicode, and bytes
    isinstance(x, basestring)
    
    # Python3
    isinstance(x, str) or isinstance(x, bytes)

instead?  I understand that the code is designed to catch any infinite containers, but I suspect that the existing code will only work on strings and string-likes since it assumes that the repeating part of the container-in-container comes first. (i.e., if it was designed to catch repeating decimals it would catch 1/3 but not 1/6)



As a side note, I was able to avoid the exception by making the positions variable a quantity-tuple of NATOM Vec3s (rather than a non-quantity tuple of NATOM Vec3 quantities).  I haven't investigated enough to see why that fixes things, but with my proposed change either one works. (Making the whole tuple a quantity rather than each Vec3 is a better route, I think, but it would be nice to support both).