Lifecycle guarantees for target fragments

Ported from frameworks/support change id
I824eb312fbdfd6b548fe94aa2cd5b03afbaa97c7

When a target fragment was set using Fragment#setTargetFragment, all
bets were off, especially when restoring from instance state. Order of
lifecyle initialization was undefined meaning that two bugs could
occur, both of which manifested as the target fragment was not
initialized by the time the referring fragment's onCreate ran. One
could happen if the target fragment is on the back stack, the other
could happen if the target fragment was ordered unfortunately in
FragmentManager implementation details. (!)

Fix both by guaranteeing that any target fragment gets pushed forward
to at least the CREATED state before we dispatch any lifecycle events
for the referring fragment.

Add some sanity checks that try to keep developers from setting target
fragments across different FragmentManagers or from creating target
cycles, both of which are bad ideas.

Bug: 33653458
Test: CTS FragmentLifecycleTest
Change-Id: If624d4665d29e205d37b9b384322e64d6d6d3615