Previously, we only took the new head if it's heavier than the last
head. Unfortunately, this meant that F3 finalization wasn't properly
propagated to the miner.

In terms of impact:

1. It seems likely that this check was simply defensive as, prior to F3,
the new head should never have a lower weight (unless you're talking to
multiple lotus nodes, I guess...).
2. The `lastWork` field is mostly used to track null blocks. Worst-case
scenario, if we switch heads, we'll attempt to re-mine previous heights.
However, that should be relatively fast and, due to the slash filter, we
won't attempt to re-broadcast any of those blocks.

This test still doesn't pass and I'm not sure why:

1. Sync is a bit broken because it can't figure out that we already have
all the data locally.
2. But with 2 nodes, it should work. Except that, if I add some logging,
I see that sync works until the libp2p nodes just flat-out disconnect
from eachother.

We also perform this check inside `SyncSubmitBlock` so we did have an
effective filter, but this was still wrong.

We have some cases where we submit a tipset to ourselves, from
ourselves and end up calling `AddPeer` with our own ID. Ignore this case.

A side-effect of InformNewHead is to record the peer for future
chain-sync sessions. If we don't pass blocks to InformNewHead here, we
can have some difficulty bootstrapping networks.