Remove Python 2.6 support?

[Frencil]

The Problem

This is really a question for @cleder. On Build #40 I learned why there are so many tests shaped like this:

with self.assertRaises(Exception):
    foo = czml.Object(args...)

That are commented out. In Python 2.6 and below unittest.assertRaises() expects three arguments, where 2.7 and up are okay with the single argument. As a result it's impossible (or I don't know how) to build unit tests confirming exceptions and type errors are raised with invalid object creation, as in the example above.

Specifically in d6df512 I added a test for setting version on a CZMLPacket as it's instantiated where the documentation is clear that this is only valid on the document object. From personal experience with CZML I've found that setting version on other objects will result in invalid CZML, so it's an important test to have in place:

# Test that version can only be added to the document object (id='document')
with self.assertRaises(Exception):
    doc = czml.CZMLPacket(id='foo', version='1.0')

(this was commented in cd50ef3)

There are a handful of other such unit tests built within a context manager like this currently commented out in test_DateTimeAware, testCone, and testEllipsoid. Presumably they work in 2.7 and up, and presumably they're good tests to have in the suite.

Potential Solutions

1. Only build unit tests that work on all supported versions of Python (e.g. don't use a context manager with unittest.assertRaises())
2. Wrap unit tests that error on Python 2.6 in a version check so they never fire on 2.6 and below
3. Remove Python 2.6 support altogether

We're effectively doing solution 1 right now but it's limiting. I lean toward solution 3 for its simplicity, but I don't know how critical support of 2.6 is among users of this module.

[cleder]

I tend to 3) and remove python 2.6 and python 3 < 3.3 support. by now 2.7 and 3.3 + should make 95+% of all installations

[Frencil]

Thanks, @cleder. I can restrict support to 2.7 and 3.3 in a branch today, and maybe update the README some, and then I think version 0.2 will be ready to push up to PyPi. =)

[Frencil]

Resolved in #11.