fix(core): android edge to edge stabilization - #11434

Five defects in how androidOverflowEdge distributes window insets, all
reproduced on a real Android 16 device (SM-A536E, SDK 36):

- `ignore` was missing from the edge map, so a stacked value like
  `ignore,bottom` silently degraded to plain `bottom`.
- parseEdges returned null for any value resolving to none (`none,none`),
  and null means "leave the view alone" - so the property became a no-op
  that stranded the view on whatever edges it had before.
- A view switched back to `ignore` never gave back the padding it had
  baked in: the listener stays installed but passes insets straight
  through from then on, so nothing undid the earlier pass.
- setPadding re-added only edgeInsets.bottom, while the inset pass had
  applied max(navigation bar, ime). Any setPadding while the keyboard was
  open collapsed the keyboard gap.
- Removing one androidOverflowInset subscriber tore down the native
  listener for all of them, and disposeNativeView left insetListenerIsSet
  true, so a recycled native view never got the listener back and the
  event went quiet after navigating away and returning.

Also drops the shortcut that returned WindowInsetsCompat.CONSUMED when a
pass reported no system bars: it skipped the padding reset and never
notified `dont-apply` listeners when the bars went away.

parseEdges moves to its own internal module so it can be unit tested
without the whole view stack, and org.nativescript.widgets.d.ts picks up
OverflowEdgeIgnore, getEdgeInsets, getImeInsets and setInsetListener.

Seven pages under pages/ete, reachable from the ete/hub entry on the main
page. Each one is readable from a screenshot alone: a shared colour legend
means the ring you see around the content IS the padding the view applied,
so a wrong inset shows up as a wrong-sized band rather than a number
someone has to go looking for.

- edges     walks every androidOverflowEdge value, including the stacked
            `none,none` and `ignore,bottom` regressions
- nested    dont-apply parent whose JS handler rewrites and consumes the
            insets, with a child that pads by what survived
- ime       keyboard insets, and setPadding while the keyboard is open
- lifecycle the ignore reset sequence, and whether the inset event still
            fires after the native view has been recycled
- modals    fullscreen vs floating modal windows
- bars      statusBarStyle, bar colours, and live system theme switches
- scroll    the everyday pattern: list scrolling under the navigation bar

Pages that let the probe overflow keep their controls out of the
navigation bar's reach - a bottom-pinned button there is not tappable.

The bar icon appearance is chosen from the theme when the style is
applied, and the activity survives a dark mode switch, so without this
the bars keep the old theme's icons until the app restarts. Confirmed on
an Android 16 device before merging: a live switch to light mode left the
navigation bar dark-on-light-icons, while a fresh start in light mode got
it right.

Insets came from Type.systemBars() alone, which leaves the display cutout
out. In portrait the two coincide and nobody notices, but rotate the
device and the camera moves to an edge that has no bar - so `none`, which
reads as "keep my content clear of the system UI", let content slide
under it.

`cutout` appends to any existing value (`none,cutout`, `top,cutout`) and
folds displayCutout() into the insets being distributed. It is a modifier
rather than an edge: the bit is masked off before anything asks which
edges were requested, so it composes with the whole vocabulary instead of
multiplying it. Whatever is consumed of the cutout is withheld from
children too, so a nested view that also asked for it does not apply it
twice.

Left opt-in rather than made the default: folding the cutout in
everywhere would silently add padding to landscape layouts that have
already worked around this.

Measured on an Android 16 device in landscape, where systemBars is
0,84,0,42 and the cutout is 88,0,0,0: `none` pads 0,84,0,42 and
`none,cutout` pads 88,84,0,42.

…ange

refreshEdgeToEdge re-styles the activity's window, but a fullscreen modal
has its own dialog window styled separately when it opens. Nothing
re-applied that one, so a modal open across a dark-mode switch kept the
bar icons of whichever theme was active when it was shown - white icons
on a light navigation bar, and the reverse switching back.

The dialog fragment now watches its own configuration changes and
re-applies when the night mode bit actually moves, so the cost is one
comparison per configuration change rather than a restyle on every
rotation.

Verified on an Android 16 device with a fullscreen modal open across a
switch in both directions.