Fix routing to account for rawToContentPos (#16497)
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.
