ci: port CircleCI workflow to GitHub Actions

[galargh]

Description

This PR ports .cicleci/config.yml to .github/workflows/ci.yml. I have decided to do that because I didn't have access to CircleCI yet so I couldn't inspect the builds and because we're leaning towards using GitHub Actions going forward across org(protocol/.github#251).

Speedup

The new workflow already tries to be address the CI speed issue: https://github.com/filecoin-project/fvm/issues/76

Caching

It uses rust cache here https://github.com/filecoin-project/fvm/blob/c18399245cfff55d6d1ad19cc65bca43456c91ea/.github/workflows/ci.yml#L28 and here https://github.com/filecoin-project/fvm/blob/c18399245cfff55d6d1ad19cc65bca43456c91ea/.github/workflows/ci.yml#L47 which caches:

• ~/.cargo/registry/index
• ~/.cargo/registry/cache
• ~/.cargo/git
• ./target

This is pretty much on par with what we used to do in CircleCI though so this is not going to affect the build times.

Removing -force flag

It also removes -force flag from https://github.com/filecoin-project/fvm/blob/c18399245cfff55d6d1ad19cc65bca43456c91ea/.github/workflows/ci.yml#L50-L51 which shaves off around 2m 30s from builds that successfully downloaded cache. I believe this is safe to introduce since cargo install performs update if needed: rust-lang/cargo#7560

Release

I propose that we merge this and let the new action soak for a while to see how it compares with CircleCI. If it works as expected and is faster, we can make the new checks required and deprecate the CircleCI workflow.

Triggers

I think the CircleCI workflow runs on every commit so I set the GitHub Action workflow the same way.

Testing

• CI run that got all deps from cache https://github.com/filecoin-project/fvm/actions/runs/1658014586/attempts/2 - 6m 9s
• CI run that had to populate the cache https://github.com/filecoin-project/fvm/actions/runs/1658014586/attempts/1- 23m 19s (this should only ever happen on rust version changes or if there are no builds for over a week)

[raulk]

LGTM, and it seems to run 50% faster! 🎉

Only nit is that the test-wasm job name is a bit misleading because this job is actually not running WASM tests. Can we just call it build for now?