Whitespace formatting in document content

The version currently in production (5.24) normalises the whitespace in document contents. This has a few effects:

- If you have a line like `A B C`, it will be shown as `A B C`.
- The text is split by linebreaks (one or more `\n`), and each line is wrapped in a paragraph `

` element. Paragraphs are semantic elements, but they are also styled with some extra spacing. (c.f. #1477)

I was looking at this while working on #1934. There is actually some code to preserve white space but it is not correctly implemented, so the whitespace is collapsed anyway.

Anyway, the advantage of doing it like this is that for many corpora, it makes the content more readable. And in many cases, splitting on linebreaks is semantically sound. I pushed this because it's better accessibility-wise, to actually make `

` elements when applicable.

"when applicable" being the key phrase, but that is not a valid assumption. The whitespace formatting looks good for corpora like Troonredes, but does not work for corpora like DBNL which also includes poems and songs.

Since Textcavator displays research data, I think it makes more sense to just display the whitespace as-is, and not add semantic encoding in the form of paragraph elements.

I should add: it's also possible to provide your text as an array of strings, which Textcavator interprets as an array of paragraphs. This behaviour seems fine to me, and like a decent way to encode paragraph breaks in the source data.

So a sensible system could be:
- Textcavator displays all whitespace as-is and does not "interpret" `\n` (by making it a semantic tag).
- If you provide your text as an array, instead of a single string, those denote paragraphs, which are shown as `

` tags. Content within a paragraph is still displayed as-is.

But there are some hang-ups:

- Many existing corpora use a single `\n` between paragraphs. If you display the linebreaks as-is instead of adding paragraph margins, it's less readable.
- You currently cannot encode array values in the corpus form. I expect we'll add this at some point, tough, because it's also very useful for keyword fields. I don't think it's essential; if you want visually spaced out paragraphs, you can just use `\n\n`.

Possible solutions:

- Switch to the setup described above, but that means many existing corpora will look worse.
- Keep normalising whitespace, but then we need to accept that Textcavator is not suitable for some types of text (such as poetry), which is not great.
- Add a parameter for fields, which controls whether or not the whitespace should be normalised in the frontend, to support legacy data. This is probably the best outcome, but adds complexity.
- Show normalised content, but add an option in the view to see the raw string data. Not great: this transfers the complexity to the user. (Hard to imagine but most people actually spend very little time thinking about whitespace formatting.)