Fix handling of mrows that look like \left...\right to be texClass INNER. (mathjax/Mathjax#2584)

[dpvc]

This PR removes the check that there either be no previous element or that it be marked as fnOP in order for an mrow to be marked as TEXCLASS.INNER. That was incorrectly preventing \left...\right constructs from being treated as the correct class.

With this PR, f\left(x\right) will be spaced as it is in actual TeX (with a bit of extra space between the f and the open parenthesis). It also means that

<math>
  <mi>f</mi>
  <mrow>
    <mo>(</mo>
    <mi>x</mi>
    <mo>)</mo>
  </mrow>
</math>

will also be spaced the same way. Some may object to that. There are several ways to prevent it. One would be to set the mathMLSpacing property to true on the output jax. Alternatively, you can modify the input to be

<math>
  <mi>f</mi>
  <mrow data-mjx-texclass="ORD">
    <mo>(</mo>
    <mi>x</mi>
    <mo>)</mo>
  </mrow>
</math>

or

<math>
  <mi>f</mi>
  <mo rspace="0">&#x2061;</mo>
  <mrow>
    <mo>(</mo>
    <mi>x</mi>
    <mo>)</mo>
  </mrow>
</math>

One could also write a MathML input jax post-filter to add the data-mjx-texclass="ORD" to recover the earlier behavior.

Resolves issue mathjax/MathJax#2584.

[zorkow]

This could be related to the issue @pkra had flagged in his visual output comparison.
Personally I like it, as it will make easier on the SRE site. But I will first test a bit before I approve.

[zorkow]

lgtm.

[zorkow]

One idea struck me: SRE adds invisible function applications during enrichment. We could set rspace="0" to make the visual difference between the original and enriched less pronounced.

[dpvc]

We could set rspace="0" to make the visual difference between the original and enriched less pronounced.

That would probably be a good idea in the cases where the <mrow> for the fence was added by SRE (but not on the invisible apply in general, a that can cause wrong spacing in other situations).