overlayfs: Refactor how the scratch device is deduced, again.

The previous refactoring did not uncover the full breadth of issues that
arise when trying to use /data for adb remount. In fact, there are a few
distinct use cases for the scratch device, and one function cannot
sensibly provide them all.

(1) First-stage init needs to know if there are dependent devices. This
    would be userdata, super_<other>, or system_<other>. This knowledge
    is dependent on the state in /metadata, fstab, and the kernel
    command-line.

(2) First-stage init and fastbootd need to know where the scratch
    partition is. If it's not in super_<other> or system_<other>, and
    there is no indicator on /metadata, then it might be in a dynamic
    partition.

(3) "adb remount" needs to find a place to put scratch, which
    effectively amounts to the first writable space it can find.
    However, for Virtual A/B, devices, scratch wants to be stored in
    /data, which requires more complex checks and binder calls.

Trying to encapsulate all of this into one function is too difficult, so
instead, this patch breaks GetScratchStrategy into separate functions:
one to return a physical location if a candidate exists, and another to
deduce the "boot" scratch device.

"adb remount" no longer calls GetScratchDevice, since it only needs to
know whether or not a physical candidate was possible.

fs_mgr_overlayfs_teardown calls GetBootScratchDevice, but now only
attempts to make a dynamic "scratch" partition if one definitely exists.
This makes the functionality clearer and reduces fastbootd uart spam.

Bug: 134949511
Test: adb_remount_test.sh on coral
      adb_remount_test.sh on crosshatch
      adb_remount_test.sh on walleye
Change-Id: I5f6a3677bc6adcaaf54c8ab3594643e4f285c04e