Fixup of #16477

Summary of the issue:
When writing #16477, I hadn't realized that TextInfoRegion compensated for characters that aren't part of the text info. This mapping is stored in the _rawToContentPos attribute. This compensation is necessary for character movement based routing, but not for code point offset based routing. The following would happen without this pr.

In Word, write a list item, e.g. 1. Hello
Route to the fourth cell (offset 3)
The third raw position (h) would correspond with content position zero (1)
With moveToCodepointOffset, moving to offset 0 means moving to 1 not to h. Basically, the cursor would end up at the first cell, not at the fourth.
Description of user facing changes
Routing works again in Word list items.

Description of development approach
When using moveToCodepointOffset, move to the raw position, not to the actual content position. moveToCodepointOffset expects raw positions, not content positions.
Don't use moveToCodepointOffset when the content position is 0, since we can simply collapse the textInfo at the start of the reading unit and return that. Note that moveToCodepointOffset would fail for everything up to offset 3 anyway, since it wouldn't be able to move.

This reverts commit a98855d.

Reverts #16477 , #16497

Issues fixed
None

Issues reopened
Reopens #10960

Reason for revert
Feature turns out to be unstable.

Can this PR be reimplemented? If so, what is required for the next attempt
Use a feature flag
Ensure issues reported in Fix routing to account for rawToContentPos #16497 (comment) and Fix routing to account for rawToContentPos #16497 (comment) are covered by the fix

Fixes #10960
Replaces #16477, #16497

Summary of the issue:
There are cases where moving one character on a textInfo instance actually moves more than one unicode point offset. This is described by @mltony in the doc string for textInfos.TextInfo.moveToCodepointOffset.
This causes of by one errors when cursor routing, since we're asking the textInfo to move by 1 characters, that might be presented by two or even more characters within the liblouis mapping.

Description of user facing changes
Cursor routing should be more reliable.

Description of development approach
@mltony's creation of moveToCodepointOffset allows us to move x code points from the start of the reading unit. As we're using 32 bit encoding for liblouis, every character as presented by liblouis is equal to one code point. Therefore we can safely assume that this method to move is much more reliable than the previous method.