Py3k/v1

This set of changes ports tlslite to Python 3, while maintaining compatibility with Python 2.6.

When reviewing, please consider that I tried to follow these principles:

* each change is designed to work individually, in the sense that 2.6 support is not affected.
   In each case, the 2.6 support should be obvious by review. For example, adding b"" prefixes
   to many strings doesn't change the semantics of the strings in 2.6 at all; it only affects 3.x.
  You need all patches to make the test suite pass.
* each changeset groups a type of changes across the entire code base. In some cases, alternatives
  are available (e.g. a different naming of the compat functions). This shouldn't affect the other patches   
  (except perhaps where two changes affect the same line)
* all cryptographic and protocol algorithms use bytes objects in 3.x; character strings are never used (see remark below, though).
* the code base sometimes distinguishes between "bytes" and "strings", referring to the 2.6 bytearray and str types. In 3.x, the bytearray and bytes types are used, respectively, making the "string" functions a misnomer. However, I kept the names to simplify the review. If you want to refactor, I suggest to call them RW (for byte array) and RO (for str/bytes), e.g. ROtoRW and RWtoRO, instead of stringToBytes and bytesToString.
* no attempt was made to support versions before 2.6.
* the code has only been tested with the pure-Python code. Supporting any of the add-on libraries in 3.x probably requires further changes.

If you have questions about the patches or would prefer modifications before applying them, let me know.

One open issue is the datatype for host names. I propose that host names become "native" strings, i.e. the respective type str. For 3.x, this would require to encode and decode host names communicated over wire, and I haven't studied what encoding TLS would use for host names.

A similar issue might apply to the other "text" parameters of the protocols, such as user names and passwords. Unless TLS specifies an encoding, it might be best to support both byte strings and unicode strings on input, and produce byte strings on output. OTOH, if TLS specifies an encoding, I again propose to make them native strings.