Fix tables StringColumn unicode

[manics]

Replacement for #133

See comment in hdfstorageV2.HdfStorage.append (9e1d8e0) for the full explanation

Probably needs a doc update to say string column sizes must be given as the number of bytes not the number of unicode characters.

[manics]

The last commit fails on Python 2.7 with the inexplicable error:

    def arrays(self):
        """
        Check for strings longer than the initialised column width
        """
        for v in self.values:
>           if sys.version_info >= (3, 0, 0):
E           AttributeError: 'module' object has no attribute 'version_info'

https://travis-ci.org/ome/omero-py/jobs/620734836
Python 3 is fine, and the code works fine in the rest of omero-py ¯\_(ツ)_/¯

[joshmoore]

There is also an omero.sys module which is likely what Py2 is picking up. There are existing import gymnastics to handle that.

[joshmoore]

(Title is probably also a bit off now, eh? 🙂)

[manics]

It might be possible to simplify this by moving the conversion into StringColumnI.arrays() so bytes are always returned. This assumes arrays() isn't used anywhere else.

[manics]

See last commit on #145 re the last comment

[sbesson]

• integration tests failed today with the ValidationException message. After adjusting the column length as per
  ome/openmicroscopy@ebe2f98, a re-execution of the tests passed.

• tested a minimal annotation workflow using a dataset with one image, the following annotation CSV file and the omero-metadata plugin (with a fix to be opened separately)

  Image Name,Term
  test.fake,მიკროსკოპის პონი
  

  A table was successfully created with the string containing Unicode characters as expected.

Overall, the changes ensure string arrays are systematically encoded before creating a StringColumn. The additional unit tests covering the ValidationException thrown on incorrect string length as well as the broken getWhereList query are very valuable.

As proposed this morning, merging this and releasing as a quick 5.6.dev9 pre-release of omero-py which can be consumed by OMERO 5.6.0-m4. Given it includes a proposed breaking change similar to the return of bytes in the FileAnnotation API, the cleanup PR can be reviewed composedly as a follow-up.