[DEVCON-2524] output deploy queue to checkrun summary

[tlin4194]

Issue:

Previously, when a revision is queued, we mark the github status as queued but have no other indication in the check run itself that this check run is waiting on something.
Users have to figure out which check run is holding up the queue which is difficult because deploys for a root can happen off any branch. We can figure this out using the temporal UI however it would be a better CX if we could just surface the queue itself in the check run.

Part 1

Add queue info to checkrun summary on creating new check run or unlock signal. Queue info is shown as [commit SHA](link to specific check run)

Part 2

Check run summaries do not get updated in cases where a a Terraform workflow is pending Confirm/Reject checkrun action between Plan and Apply steps, since the deploy queue lock only tracks the "Unlock" checkrun action.

• Surfaces deploy queue from queue package to deploy/terraform package. Some complication using Queue structs here due to cyclic dependencies between the two packages.
• To avoid restructuring the two packages, instead we will pass the GithubCheckRunCache (github package) over from queue worker to deploy/terraform workflow.
• StateReceiver will use GithubCheckRunCache to update checkrun summaries for each revision on the queue when a Confirm/Reject action is pending.

Test Plan

1. Recreating Unlock action: open 2 PRs, run atlantis apply -f on PR 1, and try to merge PR 2. PR 2 will be locked by confirm reject action on PR 1. Any subsequent queued deploys will show up as queued commits (with corresponding links) in checkrun summary.
2. Recreating diverged confirm/reject action: run atlantis apply -f on unmerged PR 1 and confirm. Create PR 3 and run atlantis apply -f on unmerged PR 3.
3. Merged PR 1 deploy will update to to show pending action on PR 3. Links will go directly to the specific run instead of just the commit in case there were multiple forced applies on PR 1.

Improve Test Cases

Fix queue_test and updater_test where assertions in CreateOrUpdate were not getting caught since the function is called within a temporal worker.

[tlin4194]

/ptal #dev-console

[asubrocky]

I think this might pose some non-determinism errors, see https://community.temporal.io/t/workflow-determinism/4027, but I could be wrong. If it does, let's add some workflow versioning here

[tlin4194]

Current PR is tested on staging, with behavior as expected.
The only issue is that after a deploy pending on confirm/reject action gets unblocked, if the queue is currently locked the state receiver cannot restore the unlock button on the checkruns for queued items. The workaround in the UI is that users will just click on the linked previous checkrun unlock from there.

The actual solution requires exposing queue lock state to state receiver. This would require a significant code restructure since LockState cannot be imported to Terraform package without a cyclic dependency. The following steps are moved to a separate PR.
Steps:

1. Add lockstate logic to state receiver
2. Move lockstate to independent package so that lockstate can be imported in state receiver
3. Split up queue interface into 2 interfaces due to interface bloat, one for deploy worker, one for terraform runner.
4. Fix test cases