Devcontainer-based CI flow

[parkan]

(cleaned up version of #585 -- the history got so hairy that internal rebasing broke on that branch)

MOTIVATION

the workflows in this repo were historically based on PL templates/work patterns, with complex matrix builds, multi-container orchestration, and a huge number of action dependencies

this resulted in repeated breakage due to actions changing, versions not being pinned fully/going out of sync, new golang releases changing linting rules, etc

numerous efforts were made to get that CI workflow working reliably (#443, #436, #467, #581, etc) but ultimately this all feels like threading water at best

to make matters worse, testing the workflows locally is a giant headache because even act doesn't provide an isomorphic environment to what happens on the runners and is not feature complete; normal make test output diverges heavily between local dev and CI

PROPOSAL

• use devcontainers for reproducible, isomorphic workflows
• use go.mod as source of truth for go version as much as possible (already implemented)
• run DB backends inside devcontainer, lock versions at build, avoid orchestration and IPC issues
• run all actions that don't touch the releaser flow inside the devcontainer (much cheaper invocations, single container)

NOTE: we're using https://github.com/parkan/github-actions to run a rootless podman devcontainer because:

• the official microsoft devcontainer ci actions are shockingly broken and don't match the local devcontainer cli/vscode behavior
• I run a podman dev environment locally and see no reason to use legacy docker over rootless OCI, however my actions support docker if desired

NOTES/REMAINING

• the releaser workflows still use the old paths; they are a bit brittle but seem to be working at the moment so I'm going to leave them alone
• branch protection rules reference the removed workflows, we should repoint them to this one
• probably needs a better name

[lanzafame]

This looks good to me. Minor comment on removing some of the old test util functions.

[parkan]

ok, this was rebased onto the good tag (v0.6.0-RC3), however main is ahead of that tag... I'll repoint onto main for now and evaluate how to best return main to a good state

[parkan]

after some consideration I'd propose saving current main in a new branch (deprecated/wallet) for posterity and force pushing to v0.6.0-RC3, after which this will apply cleanly and we'll have clean history on main

[parkan]

I've saved the work in https://github.com/data-preservation-programs/singularity/tree/abandoned/main -- opting for branch over tag as tags may get GC'd if not referenced by a branch (it may also confuse goreleaser)

@ianconsolata could you give me prems to change branch protection rules, or temporatily un-protect main? I will also need access to this to change the checks required for merging to the ones from this PR