Crumb of deleted parent should be discarded, but not when trashed.

[sybrew]

When a child's parent page is deleted from the database, WordPress cannot resolve the parent-child relationship.

Then, when outputting TSF's breadcrumbs, we will see "Untitled" in the breadcrumb instead of the parent page, which has a link leading to the homepage.

We should verify that the parent exists before adding a link to the breadcrumb.
This check should not incur additional database requests since we must look up the parent page to find its URL anyway.

It'd be best to fix this inside the The_SEO_Framework\Data\Post::get_post_parents() method, which should also fix the issue below.
Breadcrumbs do not use this method yet, so that must change.
Moreover, we should also cache the results of this method, like we did at The_SEO_Framework\Data\Term::get_term_parents().

When a page is deleted via the user interface, WordPress assigns the grandparent as the parent, if any. We should mimic this behavior in The_SEO_Framework\Data\Post::get_post_parents().

When a page is trashed but not deleted, WordPress still assumes the page exists -- only the URL will change, and it becomes inaccessible to non-editors (cite?). We must then still query the post object as a parent...

"The issue below:"

...but the Canonical URL Notation Tracker will assume all parents are gone. This is wrong, and we should fix that together with this issue. Perhaps this is more difficult to track. Moreover, on List Edit, the tsfTermSlugs.store() cacher should purge deleted posts and their children so that we can reassert the parent/child relationship in a subsequent request.