switch to pytest

[pytest](http://doc.pytest.org/en/latest/) makes writing tests more fun.

of course targeting unittests at first was an obvious choice, but we should think about if we can switch to something nicer to use.

pytest makes you write top-level functions and assert statements. you don’t need to derive from classes (saving a pointless indentation level) or search for a `assert*` method.

IMHO for something like tests, fun is _crucial_. and with unittest, i quickly lose interest and self-discipline when trying to out _again_ if i want `self.assertSomething` or rather `self.assertOMGDoesThisNameNeverEnd`. also, as i already see in the IRkernel tests, we now have millions of methods on one class instead of splitting the tests nicely into files.

the data-driven tests showcased in [test_ipykernel.py](https://github.com/jupyter/jupyter_kernel_test/blob/master/test_ipykernel.py) as well as helper functions can be realized via [fixtures](http://doc.pytest.org/en/latest/fixture.html).

e.g. we could set up a fixture that retrieves a cached kernel instance and runs its data-driven tests on instantiation:

``` py
kernel_data = {
'kernel_name': 'python3',
'code_hello_world': 'print('hello, world')',
...
}

@pytest.fixture(scope='module')
def kernel():
return jkt.kernel_tester(kernel_data)
```

and then proceed to test:

``` py
def test_thing(kernel):
reply, output_msgs = kernel.execute(code='import sys; print("oops", file=sys.stderr)')
assert output_msgs[0]['msg_type'] == 'stream'
assert output_msgs[0]['content']['name'] == 'stderr'
assert output_msgs[0]['content']['text'] == 'oops\n'
```

Start by reviewing the existing unittest-based tests in this repository and compare their structure with the data-driven and fixture examples in test_ipykernel.py. Determine the migration scope and how the suite is currently run; done means the tests use pytest conventions and continue to pass under the project's test command.

Written by the indexing model from the issue text.