This commit fixes a regression introduced in 70968d46.

This bug was introduced in 140f8fedb1

A regression was introduced in d564e4931. Before that commit you
could use key up to jump into position zero of a multiline TextEditor
if the cursor was somewhere in the first line. Since that commit the
keypress had no effect. This change restores the earlier behaviour.

This commit fixes an issue when using large lineSpacing, where the caret
would jump to the end of the previous line when clicking between lines.
With the new behaviour the line spacing is considered to belong to the
previous line.

The commit also changes the behaviour observed when clicking in the
empty space before the first line. Until now the caret would jump into
the first character position. Now it behaves as if the space before the
first line would belong to the first line.

Co-authored-by: Roland Rabien <figbug@gmail.com>

This provides an improved user experience, allowing cursor movement
directly from the keyboard.

- Fixes an off-by-one error when navigating by rows, caused by treating
  the table header as a row. The table header now has the header
  accessibility role.
- Fixes a bug where reordering table columns would cause the table to
  become inaccessible.
- Fixes a bug where the screen reader would try to navigate hidden table
  columns.
- Fixes an issue where moving the VoiceOver cursor to a partially hidden
  cell would cause the focus to move to the table itself, rather than to
  the cell.

The TextHolderComponent and Viewport::componentHolder don't have any
accessible semantics, so they shouldn't be included in the accessible
component hierarchy.

Previously, when navigating in a text editor by words, the cursor would
get 'stuck' after moving a single word. This issue should now be
resolved.

Additionally, the cursor position was not updated properly when
adjusting a selection, and would instead be moved to the end of the
selected range. With this patch applied, the cursor should now be set to
the correct position when modifying selections. When extending a
selection backwards, the cursor will display at the beginning of the
selected range, rather than the end.

Finally, most Android apps announce the 'skipped' characters or words
whenever the cursor is moved, but this feature was broken in JUCE. This
patch enables this feature.

These crashes could be seen in the DemoRunner when selecting items in
nested PopupMenu windows.

The TextHolderComponent and Viewport::componentHolder don't have any
accessible semantics, so they shouldn't be included in the accessible
component hierarchy.

Previously, when navigating in a text editor by words, the cursor would
get 'stuck' after moving a single word. This issue should now be
resolved.

Additionally, the cursor position was not updated properly when
adjusting a selection, and would instead be moved to the end of the
selected range. With this patch applied, the cursor should now be set to
the correct position when modifying selections. When extending a
selection backwards, the cursor will display at the beginning of the
selected range, rather than the end.

Finally, most Android apps announce the 'skipped' characters or words
whenever the cursor is moved, but this feature was broken in JUCE. This
patch enables this feature.

These crashes could be seen in the DemoRunner when selecting items in
nested PopupMenu windows.

Previously, individual components had to ask the peer to hide and show
the keyboard, by calling textInputRequired() and
dismissPendingTextInput() respectively. When an onscreen keyboard (OSK)
was required, most Peer implementation would directly hide/show the OSK
inside these function. However, the iOS ComponentPeer implementation
instead listened to the application's global keyboard focus, and only
opened the OSK when the focused component was also a TextInputTarget
with active input.

The iOS scheme seems like a better design, as it enforces that the OSK
hiding and showing is synced with the keyboard focus of the application.
In the other implementations, it was possible for a Component to call
textInputRequired even when it didn't have the keyboard focus, putting
the application into an inconsistent state. The iOS scheme also makes
the TextInputTarget interface more useful, as it enforces that the OSK
will only display for components that implement TextInputTarget, and
return true from isTextInputActive().

This patch changes all Peer implementations to match the iOS
implementation, improving consistency. Each time the global keyboard
focus changes, refreshTextInputTarget is called automatically, and the
OSK is shown if the focused component is a TextInputTarget that returns
true from isTextInputActive, and hidden otherwise. Components can also
call refreshTextInputTarget manually. This should be done whenever the
component updates the return value of isTextInputActive(). Effectively,
the Peer is now responsible for keeping track of the focused
TextInputTarget, rather than allowing individual components to hide and
show the OSK at will.

Additionally, this patch adds an option to the TextEditor to
automatically dismiss the OSK when the mouse is clicked outside of the
editor. This should improve user experience on mobile platforms, where
touches on sibling components may cause a TextEditor to gain keyboard
focus and unnecessarily display the OSK.

Previously, individual components had to ask the peer to hide and show
the keyboard, by calling textInputRequired() and
dismissPendingTextInput() respectively. When an onscreen keyboard (OSK)
was required, most Peer implementation would directly hide/show the OSK
inside these function. However, the iOS ComponentPeer implementation
instead listened to the application's global keyboard focus, and only
opened the OSK when the focused component was also a TextInputTarget
with active input.

The iOS scheme seems like a better design, as it enforces that the OSK
hiding and showing is synced with the keyboard focus of the application.
In the other implementations, it was possible for a Component to call
textInputRequired even when it didn't have the keyboard focus, putting
the application into an inconsistent state. The iOS scheme also makes
the TextInputTarget interface more useful, as it enforces that the OSK
will only display for components that implement TextInputTarget, and
return true from isTextInputActive().

This patch changes all Peer implementations to match the iOS
implementation, improving consistency. Each time the global keyboard
focus changes, refreshTextInputTarget is called automatically, and the
OSK is shown if the focused component is a TextInputTarget that returns
true from isTextInputActive, and hidden otherwise. Components can also
call refreshTextInputTarget manually. This should be done whenever the
component updates the return value of isTextInputActive(). Effectively,
the Peer is now responsible for keeping track of the focused
TextInputTarget, rather than allowing individual components to hide and
show the OSK at will.

Additionally, this patch adds an option to the TextEditor to
automatically dismiss the OSK when the mouse is clicked outside of the
editor. This should improve user experience on mobile platforms, where
touches on sibling components may cause a TextEditor to gain keyboard
focus and unnecessarily display the OSK.

Previously, setting a new look and feel would create a new missing-items
button, but would not add it to the toolbar or set the onClick callback.

The bug was triggered on Monterey where a pressure of 1 is reported
while a mouse button is being held down. This caused an extra drag
event being triggered between mouse down and up events, even if no
movement occurred.

Some Windows 11 devices have both touch screens and mouse inputs, and
these can be used simultaneously.

The Viewport (and ListBox) now check the input source of each mouse
down. If the source is not a mouse, the viewport will always enter
drag-to-scroll mode, regardless of the result of isScrollOnDragEnabled.