Accessible caret offset should be same as text length when caret is at the end of the text

Steps to reproduce:

1. Press F2
2. Type "abc"
3. Arrow left and right, including past the "c"

Expected results: The accessible caret-moved event would never include an offset of -1. Ditto when asking for the caret offset via AtkText.

Actual results: At the end of the input, the caret-moved event is fired with an offset of -1, and asking for the caret offset via AtkText results in -1.

What most other implementations do when the caret is at the end of the input is report an offset equal to the text length. When this happens, Orca can detect this and say blank.

Notes:

1. This is not a regression. It's been around for ever. Orca used to work around it specifically for gnome-shell.
2. What Orca will say currently depends on the exact version and build of Orca you have. 😇 That's because I rewrote a huge portion of Orca's accessible text support (with more changes pending). Right now, Orca corrects a negative offset to 0. Thus when you arrow past the "c", Orca will say "a". 😞 I'm about to stop that. But I'm not going to try to adjust. Orca is going to treat an offset of -1 as an error condition and be silent.

It would be great if gnome-shell (or clutter?) never returned a caret offset of -1 so Orca would automatically present the correct character (or "blank" at the end of the field).

@fmuellner: Is this an easy fix?