Reloading a morphing frame should trigger reloads on its child morphing frames recursively

[botandrose]

Hi folks, here's what seems to me to be the next obvious step after #1192 changed reload() to morph a morphing frame.

Example scenario

Imagine the following page structure: a morphing page with a morphing frame that itself includes another morphing frame, i.e.

Morphing Page > Morphing Frame Child > Morphing Frame Grandchild

Status Quo

Refreshing Morphing Page already triggers morphing reload()s on both the Morphing Frame Child and on Morphing Frame Grandchild. However, manually triggering reload() on Morphing Frame Child does NOT trigger a reload() on Morphing Frame Grandchild, but rather does a full non-morphing render. This seems inconsistent and surprising.

With this PR

Morphing pages now only trigger reload()s on their immediate morphing frame children, and then leaves it up to them to trigger reload()s on their own immediate morphing frame children, and so on down. This makes the reload behavior consistent no matter where the reload is initially triggered.

What do you think?

[botandrose]

Just pushed another two commits that expose and fix an adjacent bug that's been in Turbo for a while. Page refreshes didn't check to see if the new version of the page actually has the frame before calling reload() on it. So if a page refresh's new version would have different frames, the original frames would be "stuck" in place. This is fixed by checking to see if the replacement element actually is the same turbo frame before calling reload(). Otherwise, it just gets morphed as normal.