Deprecate aloe command

[tysonclugg]

A continuation of #114 but deprecating the aloe command altogether.

[tysonclugg]

So... I wanted you to see the result of the second commit (ie: 1 failed test) so I could then ask the question: Do you plan on using aloe to test aloe?

The failing test is because we're using coverage run -m nose in .travis.yml which now runs all tests by default (ie: my changes work). However... I couldn't get coverage run -m aloe/__main__.py running properly. Either I'm doing something wrong, or it's broken and the aloe command should be removed entirely...

[koterpillar]

Aloe command will not be deprecated just yet - it might be useful on its own.

A big issue here is #108. Nose is dead (on life support), django_nose will have a hard time with Django 1.10 because of argparse. If you are using Nose, I'll be keen to hear your thoughts there.

I support the idea here though: whatever test framework Aloe ends up with, running it with Aloe as a plugin should run Gherkin tests in addition to ones that would normally run.

[tysonclugg]

Nose still works, I wouldn't remove support for it unless there's a good reason to do so (such as if supporting nose becomes difficult).

I'd rather add support for py.test while keeping the existing nose plugin if that is an option. If still you're keen on dropping support for nose, then consider issuing a DeprecationWarning from the nose plugin and give developers some time to transition to py.test, or even something else.

Regarding "something else", one option would be to write a wrapper around unittest.TestCase and/or unittest.TestSuite (perhaps using metaclasses) such that normal unittest discovery by nose2/py.test/other would work. Make sure that generated classes can have defined class inheritance (eg: via django.test.TestCase) and then usefull stuff Django setup/teardown behaviour can be used without hassle...

[koterpillar]

See #108 for discussions of test frameworks (summary: I want it to be usable with either).