Math support

This PR is meant to resolve #1541 and #1543. Rendering math with Matrices currently works great (thanks @tilgovi for the help there), but there are still some issues around inline math, hence the "WIP" in the PR title. 

The ctrl.$render function has been rewritten to avoid the problems that were causing #1543, namely our Markdown converter removes backslashes needed to render the math. To address this we split the input up on math delimiters, and now don't run the math through our markdown converter. 

The result works well for solving that issue, and you can see in the picture below that even inline math in a basic paragraph works (see code comments). 
![inlinemath_working](https://cloud.githubusercontent.com/assets/521978/4553472/3c67c324-4e9a-11e4-8b3d-ab165bd60573.png)

However, there are some edge cases that still need to be addressed:
1. Math in blockquotes. We have to know where to put the </blockquote>.
![blockquote problems](https://cloud.githubusercontent.com/assets/521978/4553590/d62b67a2-4e9c-11e4-8672-f9915fab7328.png)
2. Math in lists. 
![list problems](https://cloud.githubusercontent.com/assets/521978/4553586/c30457c4-4e9c-11e4-885d-0783c0815f9f.png)
3. Italics or bold formatting that contains math in it, like so: `**Bold text \( 1 + 1 \) Bold text**`
![bold problem](https://cloud.githubusercontent.com/assets/521978/4553536/6aac7bca-4e9b-11e4-9cf5-841b9f412a27.png)

All of these problems are similar in what's happening: our new process breaks up the text based on math delimiters, so our Markdown renderer doesn't know what to do with `**Bold text `

I will update this opening comment as I make progress, but I thought since this is a difficult problem, it would be good to get some early feedback. 


<!---
@huboard:{"order":12.5,"milestone_order":1558,"custom_state":""}
-->

+0

I think it's better to look at a parser we can extend, but I'm not opposed
to this as is.
On Oct 17, 2014 2:02 AM, "Aron Carroll" <notifications@github.com> wrote:

> In h/static/scripts/directives/markdown.coffee:
>
> > +            # so that the math is inline.
> > +            else
> > +              markdown = $sanitize convert value.substring(endMath, match.index)
> > +              tagLength = htmlElement.exec(markdown)[0].length
> > +              parts.push markdown.substring(0, markdown.length - (tagLength + 1))
> > +          # Text follows a case of inline math, we must remove opening <p> tag.
> > +          else if i - 1 >= 0 and indexes[i - 1].toString() == "\\)"
> > +            markdown = $sanitize convert value.substring(endMath, match.index)
> > +            tagLength = htmlElement.exec(markdown)[0].length
> > +            parts.push markdown.substring(tagLength, markdown.length)
> > +          else # Block Math or no math.
> > +            parts.push $sanitize convert value.substring(endMath, match.index)
> > +        i++
> > +
> > +      scope.rendered = $sce.trustAsHtml parts.join('')
> > +      if MathJaxFallback
>
> Okay, while I really appreciate the time and effort you've invested in
> this. I want to ask one more time, do we really *need* inline math right
> now? I know it's nice to have but I think people could get by with just
> blocks.
>
> This code is extremely hard to follow, there are so many areas that are
> prone to bugs and I can promise that this will rot if we leave it in here.
> In three months I have a strong feeling no-one will want to touch it.
>
> Really it looks to me like we need to look into finding a markdown parser
> such as markdownjs[1] that allows the syntax to be extended and implement
> this using a proper parser rather than re writing the html.
>
> I think we have wonderful support for blocks of mathematics right now.
> Lets ship that, keep the code clean and then look at this again when we
> have time.
>
> Thoughts?
>
> [1] https://github.com/evilstreak/markdown-js
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/hypothesis/h/pull/1558/files#r19007908>.
>