Remove white-space wrapping because it breaks box mode hints

[lwinkler-mathspace]

[Please note, I haven't built the release package correctly here. I think I need to increment the release version number and build again before we merge this - I just want the idea itself to be reviewable first.]

We recently fixed a bug that manifest on recent versions of Chrome, whereby whitespace would wrap, breaking the input for certain expressions:

https://github.com/mathspace/msquill/commit/5dc79e352751376b55e179002fdb4b27172cb17e

This bug has re-appeared for so-called box mode hints, where the horizontal space available is more constrained and the line break appears in a different place in the content (repro described below).

[Please ignore the mathematics, which has no relation to the question!]

Our existing fix prevents wrapping within non-leaf class elements, but in this instance, the line is instead being broken between non-leaf elements. ie. the elements themselves aren't being wrapped, but the mq-root-block

This change removes the normal whitespace wrapping altogether, and also the now-redundant specialisation from the previous fix, which restored no-wrap for specific nestings of elements. Of course, this feels risky, because it must have been added for a reason!

Perhaps there is a further, more specific place that we can overwrite this instead?

---

Repro:

To see the problem locally requires a subproblem with box-mode type hints.

You can visit http://localhost:8000/debug/#!/problem-preview, enter problem template ID 3930, Show and then Try this problem. You can then request two hints - the second hint will trigger "box mode":

[asavoy]

@lwinkler-mathspace The main thing that top-level wrapping is for, is so that long expressions... I'm thinking series expressions like "1 + 3 + 5 + 7 + 9" get wrapped at some point reasonable if they are too wide for the screen. Could we check to see what happens in that case? Would it get clipped? Also not sure how often this happens in our content. Otherwise the suggestion makes sense.

[lwinkler-mathspace]

@lwinkler-mathspace The main thing that top-level wrapping is for, is so that long expressions... I'm thinking series expressions like "1 + 3 + 5 + 7 + 9" get wrapped at some point reasonable if they are too wide for the screen. Could we check to see what happens in that case? Would it get clipped? Also not sure how often this happens in our content. Otherwise the suggestion makes sense.

I do eventually get a broken line like so:

First the individual pieces of content re-flow (in this box-mode context):

[asavoy]

@lwinkler-mathspace Pretty sure it looked like that before - wrapping never really worked great. So if we're fixing the issue with box mode hints wrapping with this then it looks good to me.

[lwinkler-mathspace]

@lwinkler-mathspace Pretty sure it looked like that before - wrapping never really worked great. So if we're fixing the issue with box mode hints wrapping with this then it looks good to me.

I subsequently realised that my test that had showed this working was against production, instead of local (tested in the wrong browser tab).

Accordingly, I have added another commit which re-attempts the alternative solution to this problem, which is to set the cursor width to 1px (the cursor itself is a block element, which has only the left border visible, but actually consumes more space, which is what triggers the wrapping). The hypothesis is that setting the cursor to 1px width and retaining the margin offset of -1px means that wrapping doesn't happen.

This is indeed the case, but there's still a small problem:

Without any content in the box, the height of the element grows (once the width is set).

If we can resolve this problem, this will likely be a better solution to all the wrapping issues.