Fix parent<->child mixup in UnwindBlock

Summary:
D4929 faithfully backported this line from Core, however the original
code has this part backwards.

In this if-statement, the idea is to check that the tip has not
changed from previous loop iteration. If so then actually
to_mark_failed_or_parked is the parent block of invalid_walk_tip,
not the other way around.

The code as-is would end up marking all disconnected blocks as fully
failed (or parked) where the intention was to mark all but the lowest
as failedparent (parkedparent). This doesn't change much in practice since
the reconsiderblock / unparkblock will clear all children anyway, and
the automatic unparking also doesn't care whether things are parked or
parkedparent.

A side note:
This whole function is in fact a bit crazy now as it's attempting a very
slippery task by trying to invalidate a chain while the tip might be
changing on every iteration, due to other threads. If the tip actually
does end up changing for some reason, then the function doesn't really
handle it that well anyway. Backporting 16849
(to ensure tip doesn't change, via cs_chainstate lock) will bring back
some sanity by preventing this slippery thing.

Test Plan:

ninja check-all

As mentioned in summary, there is little noticeable behaviour change
so I don't have a test for this, at least not now.

Reviewers: #bitcoin_abc, deadalnix, fpelliccioni

Reviewed By: fpelliccioni

Differential Revision: https://reviews.bitcoinabc.org/D5041