fs_mgr_overlayfs: Support remounting submounts

The move mount motions logic are built on top of heuristics and allow
non-fatal failures.
If the overlay was setup and mounted without reboot (this could happen
if AVB is disabled), the mount state (especially the MS_SHARED and
MS_PRIVATE flags) can still get skewed somehow, due to unforeseen errors
or resource race.
It is always advised to reboot after initial overlay setup, as the
overlay mount logic is less likely to require moving submounts when
executed by `init`, this provides the greatest chance of success.

Below is an example of the expected outcome of remounting submounts:
[precondition]
* AVB is already disabled, so overlay is setup and mounted w/o reboot
* No existing overlay; is initial overlay setup

0. /proc/self/mountinfo would contain something like:
<id> <parent id> <mountpoint> <shared/private> <filesystem>
2    1           /product     shared:2         erofs
3    2           /product/app shared:3         erofs

1. adb remount /product/app
(note how the mount flag of <3> changes to private so <30> can be
MS_MOVE later)
2    1           /product     shared:2         erofs
3    2           /product/app private          erofs
30   3           /product/app shared:30        overlay

2. adb remount /product
(note how the parent of <30> changes to <40> as the result of MS_MOVE)
(note that <3> is _not_ moved)
2    1           /product     private          erofs
3    2           /product/app private          erofs
30   40          /product/app shared:30        overlay
40   2           /product     shared:40        overlay

Bug: 306124139
Test: adb-remount-test
Test: Verified with a remount submount scenario by editing the fstab.
Test: remount /system/bin then /system and verify the submount overlay
  (/system/bin) is moved under the parent mount overlay (/system).
Change-Id: I6cdbe8c52d826a6f03fd363c909ebb0005446b96