Add release workflow

[sharnoff]

Closes #6, adapted from NeonVM's workflow as suggested.

Renamed a couple files in deploy/, which required renaming in files unrelated to this PR.

Remaining items:

• Override images in deploy/* before adding them to the release files (f5e24b0)
• Add required secrets to this repo (not needed, see: Add release workflow #9 (comment))
• Wait for Add VM informant #8 to be merged, uncomment the sections marked as pending because of it (5bc9f34)

Open questions:

• Should we build (and push?) an image for the vm-informant binary? We need a dockerfile for it anyways (used in vm_image/Dockerfile.vmdata), but an image for it probably won't be used outside of development. cc @kelvich - thoughts?
• With the added ability to expose secrets via push + tag, do we need to protect the main branch and require review for PRs? Requiring review would be inconvenient for me, but I understand the security argument.

Follow-up work:

• neondatabase/neon: Include vm-informant binaries in compute images

[cicdteam]

@sharnoff
I see only two secrets used in GHA (NEON_DOCKERHUB_USERNAME and NEON_DOCKERHUB_PASSWORD) and they are org wide, so need no set them in repo settings

[sharnoff]

@cicdteam ah wonderful - thanks!

[sharnoff]

Merging this as-is, planning on fixing workflow issues as they come up. Record of decision-making:

• Stick with Dockerhub (instead of ECR) because it was easier to adapt other examples of our workflows using it. The images are just alpine + final binary, so it's mostly ok either way, but it's always possible to move from Dockerhub -> ECR
• Push vm-informant images anyways (per discussion with @stas) — basically it doesn't matter either way, might as well go for it
• Potential concern about unprotected branch + ability to access secrets unaddressed, merging anyways. If it's still a concern, we can fix it afterwards