Fix issue #5877 with tests

This pull request prevent to have lists environments inside the headings
cells which break latex code.

- First, the function `markdown2latex` has been changed in order to
  accept a markup keyword for pandoc reader, default to `markdown` as
  before(`test_markdown.py` updated too).
- Headings cells are treated with markup `markdown_strict+tex_math_dollars`
  to remove enhancements of pandoc for lists and add math support.
- Secondly, `prevent_list_blocks` filter escape characters `. - * +`
  in headings cells to prevent `enumerate` or `itemize` environments
  in latex sections(test added in `test_strings.py`

Test files accessible at:
    <https://gist.github.com/benjaminabel/4a40d1300dcf087c8695>
Build pandoc using haskell-platform in .travis.yml

This is required because travis use ubuntu 12.04 which ships with pandoc 1.9.11 this will not be required if travis update to ubuntu 14.04 whichuses version 1.12.2.1.
Get recent pandoc in travis from ppa cran2deb4ubuntu

This ppa:<https://launchpad.net/~marutter/+archive/ubuntu/c2d4u> contain
a backport of pandoc trusty package in precise. It can be used until
travis update his environment to ubuntu 14.04.
Move language info from kernelspec to kernel_info_reply
Use language_info instead of kernelspec in nbconvert
Remove language info from kernelspec test
Update docs about kernelspecs and kernel_info_reply
Add language_info field to message spec tests
save future compile directives from ipython -i module.py
widget registry
registering core widgets
Adding custom keys for core jptr notebook
jupyter -> IPython
Merge pull request #6493 from SylvainCorlay/python_widget_registry

Creating a widget registry on the Python side.
Merge pull request #6793 from takluyver/langinfo

Move language info from kernelspec to kernel_info_reply
Fix terminals with Tornado 3

The websocket handler auth checking was calling clear_cookie(), which
threw an error because it doesn't make sense for Websockets. It doesn't
seem important, and we silence it in our other websocket handlers, so
silencing it here too.
Remove EventManager reset methods, because they violate encapsulation.

The whole idea of the EventManager is that you can register hooks
without worrying about what hooks other pieces of code might be
registering. The reset methods violate this separation of concerns,
since they will blow away everyone else's hooks too. (See gh-6680 for
an example of this breaking things.) Since there is never any safe way
to use them, we simply remove them entirely.
Reset the interactive namespace __warningregistry__ before executing code

Fixes #6611.

Idea:

Right now, people often don't see important warnings when running
code in IPython, because (to a first approximation) any given warning
will only issue once per session. Blink and you'll miss it! This is a
very common contributor to confused emails to numpy-discussion. E.g.:

In [5]: 1 / my_array_with_random_contents
/home/njs/.user-python2.7-64bit-3/bin/ipython:1: RuntimeWarning:
divide by zero encountered in divide
  #!/home/njs/.user-python2.7-64bit-3/bin/python
Out[5]:
array([ 1.77073316, -2.29765021, -2.01800811, ...,  1.13871243,
       -1.08302964, -8.6185091 ])

Oo, right, guess I gotta be careful of those zeros -- thanks, numpy,
for giving me that warning!

A few days later:

In [592]: 1 / some_other_array
Out[592]:
array([ 3.07735763,  0.50769289,  0.83984078, ..., -0.67563917,
       -0.85736257, -1.36511271])

Oops, it turns out that this array had a zero in it too, and that's
going to bite me later. But no warning this time!

The effect of this commit is to make it so that warnings triggered by
the code in cell 5 do *not* suppress warnings triggered by the code in
cell 592. Note that this only applies to warnings triggered *directly*
by code entered interactively -- if somepkg.foo() calls
anotherpkg.bad_func() which issues a warning, then this warning will
still only be displayed once, even if multiple cells call
somepkg.foo(). But if cell 5 and cell 592 both call
anotherpkg.bad_func() directly, then both will get warnings.

(Important exception: if foo() is defined *interactively*, and calls
anotherpkg.bad_func(), then every cell that calls foo() will display
the warning again. This is unavoidable without fixes to CPython
upstream.)

Explanation:

Python's warning system has some weird quirks. By default, it tries to
suppress duplicate warnings, where "duplicate" means the same warning
message triggered twice by the same line of code. This requires
determining which line of code is responsible for triggering a
warning, and this is controlled by the stacklevel= argument to
warnings.warn. Basically, though, the idea is that if foo() calls
bar() which calls baz() which calls some_deprecated_api(), then baz()
will get counted as being "responsible", and the warning system will
make a note that the usage of some_deprecated_api() inside baz() has
already been warned about and doesn't need to be warned about
again. So far so good.

To accomplish this, obviously, there has to be a record of somewhere
which line this was. You might think that this would be done by
recording the filename:linenumber pair in a dict inside the warnings
module, or something like that. You would be wrong.

What actually happens is that the warnings module will use stack
introspection to reach into baz()'s execution environment, create a
global (module-level) variable there named __warningregistry__, and
then, inside this dictionary, record just the line number. Basically,
it assumes that any given module contains only one line 1, only one
line 2, etc., so storing the filename is irrelevant. Obviously for
interactive code this is totally wrong -- all cells share the same
execution environment and global namespace, and they all contain a new
line 1. Currently the warnings module treats these as if they were all
the same line.

In fact they are not the same line; once we have executed a given
chunk of code, we will never see those particular lines again. As soon
as a given chunk of code finishes executing, its line number labels
become meaningless, and the corresponding warning registry entries
become meaningless as well. Therefore, with this patch we delete the
__warningregistry__ each time we execute a new block of code.
Merge pull request #6436 from thomasballinger/fix-6430

Saving future compile directives from ipython -i
Merge pull request #6680 from njsmith/reset-warning-registry

Reset the interactive namespace __warningregistry__ before executing code