After the changes in PR #14428, the [`normalizeWhitespace` option](https://github.com/mozilla/pdf.js/blob/1087b4dffdf5884ad17669fda54c59dd810667d3/src/display/api.js#L1072-L1073) is now in most (or perhaps even all) cases being ignored and treated as if `normalizeWhitespace = true` is passed to the `PDFPageProxy.{getTextContent, streamTextContent}` methods.[1]

With the changes in PR #14428 we're now handling all whitespaces *consistently* in the `PartialEvaluator.getTextContent` method, which together with other (somewhat) recent improvements have fixed many textLayer issues by handling both coalescing of repeated spaces and proper space insertion between text chunks.
Looking briefly at this code, it seems to me that trying to re-instate "proper" `normalizeWhitespace = false` handling would be quite difficult and would likely hurt readability (assuming it's even at all possible now).
Furthermore, note that in both the viewer and the browser-tests we're only ever using `normalizeWhitespace = true` which means that the other code-path isn't really used all that much.

All-in-all, I'd probably suggest that we simply remove the `normalizeWhitespace` option and make the relevant methods always carry out the normalization since that's what e.g. the viewer uses.

Any thoughts/opinions about this?
/cc @timvandermeij 
/cc @calixteman 

---
[1] One example is the `issue6612.pdf` document in the test-suite, added together with the option, where "regular" spaces are now being returned regardless of the `normalizeWhitespace` value.
* @property {number} [length] - The PDF file length. It's used for progress
 *   reports and range requests operations.
 * @property {PDFDataRangeTransport} [range] - Allows for using a custom range
 *   transport implementation.
 * @property {number} [rangeChunkSize] - Specify maximum number of bytes fetched
 *   per range request. The default value is {@link DEFAULT_RANGE_CHUNK_SIZE}.
 * @property {PDFWorker} [worker] - The worker that will be used for loading and
 *   parsing the PDF data.
 * @property {number} [verbosity] - Controls the logging level; the constants
 *   from {@link VerbosityLevel} should be used.
 * @property {string} [docBaseUrl] - The base URL of the document, used when
 *   attempting to recover valid absolute URLs for annotations, and outline
 *   items, that (incorrectly) only specify relative URLs.
 * @property {string} [cMapUrl] - The URL where the predefined Adobe CMaps are
 *   located. Include the trailing slash.
 * @property {boolean} [cMapPacked] - Specifies if the Adobe CMaps are binary
 *   packed or not.
 * @property {Object} [CMapReaderFactory] - The factory that will be used when
 *   reading built-in CMap files. Providing a custom factory is useful for
 *   environments without Fetch API or `XMLHttpRequest` support, such as
 *   Node.js. The default value is {DOMCMapReaderFactory}.
 * @property {boolean} [useSystemFonts] - When `true`, fonts that aren't
 *   embedded in the PDF document will fallback to a system font.
 *   The default value is `true` in web environments and `false` in Node.js;
 *   unless `disableFontFace === true` in which case this defaults to `false`
 *   regardless of the environment (to prevent completely broken fonts).
 * @property {string} [standardFontDataUrl] - The URL where the standard font
 *   files are located. Include the trailing slash.
 * @property {Object} [StandardFontDataFactory] - The factory that will be used
 *   when reading the standard font files. Providing a custom factory is useful