Simplify logic related to testing if ziptype 64 is allowed.

Galaxy dropped support for 2.4 and 2.5 so no need to catch TypeError that was being caught in previous check.

Likewise, reviewing the Python source code (zipfile.py) for both 2.6 and 2.7 as well as the official documentation, I don't believe LargeZipFile error will ever be thrown from the ZipFile constructor - it is only ever going to be thrown when an actual write occurs. Hence, I think ziptype can safely be set to 64 for all supported versions of Python. Updated the source code reflect this.
Previous changeset resulted in ziptype being set to 64 across the board, so it is no longer really needed. Drop all logic for ziptype and just assume 64 bit zip files are allowable if zip files are.
Improved logic for determining if zipfile compression is implemented.

Had the following spurious error occur in production.

Traceback (most recent call last):
  File "./scripts/extract_dataset_part.py", line 25, in <module>
    import galaxy.model.mapping #need to load this before we unpickle, in order to setup properties assigned by the mappers
  File "/opt/galaxy/web/lib/galaxy/model/__init__.py", line 13, in <module>
    import galaxy.datatypes.registry
  File "/opt/galaxy/web/lib/galaxy/datatypes/registry.py", line 5, in <module>
    import data, tabular, interval, images, sequence, qualityscore, genetics, xml, coverage, tracks, chrominfo, binary, assembly, ngsindex
  File "/opt/galaxy/web/lib/galaxy/datatypes/data.py", line 43, in <module>
    os.rmdir( tmpd )
OSError: [Errno 39] Directory not empty: '/mnt/galaxyData/tmp/516.1.all.q/tmpF25FKf'

Rework logic to check if zipfile compression is available without actually creating directories and files. This should eliminate this error and marginally improve Galaxy performance/robustness. Again looking through the Python source code as well as documentation, I believe this is equivalent to the old version.