feat: allow checkpointing to forks

[Stebalien]

Previously, lotus sync checkpoint would only checkpoint on the current
chain. Now, it can switch to a new fork.

Alternatives considered:

1. Follow a peer: sketchy.
2. Mess with the sync manager to only sync this chain: very
   invasive. (but I have a WIP patch if desired).
3. Introduce a new lotus sync fetch command to fetch a chain (to be
   paired with lotus chain sethead followed by a lotus sync checkpoint.

Changes:

1. Move the checkpointing logic into the chainstore so setting a checkpoint and syncing a different head can't race.
2. Re-enable checkpoint tests, fix, and expand them.
3. Rename Sync.SetCheckpoint to Sync.SyncCheckpoint and allow it to sync to a new fork.
4. Make Chain.SetHead unset any set checkpoints.
5. Reject checkpoints more than the fork limit in the past.

Known issues:

1. The current checkpoint mechanism is racy because we only check before we start syncing a chain. We need to push checkpoints down into the chainstore to be safe/atomic. fixed
2. Unlike lotus chain sethead, this code doesn't "invalidate" the current fork. I'm not entirely sure why we need to do that. not an issue here

[arajasek]

@Stebalien This will need an update to the lotus sync checkpoint CLI command, which currently only takes epochs as inputs (since it's basically only ever used after lotus chain sethead).

[arajasek]

2. Unlike lotus chain sethead, this code doesn't "invalidate" the
   current fork. I'm not entirely sure why we need to do that.

Because if not you might (likely will) immediately sync away from your new "set" head if you're setting far back in the past.

[Stebalien]

This will need an update to the lotus sync checkpoint CLI command, which currently only takes epochs as inputs (since it's basically only ever used after lotus chain sethead).

It can take a tipset or a height.

[arajasek]

Yup, LGTM