GitHub actions ci and refactor

[obalunenko]

With this PR I add the following enhancements:

• Follow Go community suggested project layout: https://github.com/golang-standards/project-layout
• CI/CD support for automation code checks and delivery release artifacts (executables for all platforms that could be downloaded from the repository releases page). Release initiated by adding semver tag https://semver.org/
• Add makefile automation
• Helper scripts for compiling, linting, and releasing the application

[obalunenko]

@adonovan Could you please review this PR? 🙏🏻

Demo of how GitHub actions would act:
https://github.com/obalunenko/spaghetti/pull/1/checks
Runs history:
https://github.com/obalunenko/spaghetti/actions/workflows/go.yml

And here is an example of how the releases page will look like after creating a new release with adding git semver tag:
https://github.com/obalunenko/spaghetti/releases

[adonovan]

Follow Go community suggested project layout: https://github.com/golang-standards/project-layout

This is the first time I've heard of this layout. It may well have merits for large projects, but this project is literally two .go files and zero dependencies, so I am not eager to accept this PR. It triples the number of files of code, and adds a huge number of dependencies to the tools submodule (ironically making an ideal candidate program on which to run spaghetti itself), and it doesn't materially improve any of these steps:

• documentation. The github and pkg.go.dev pages are already perfectly clear and discoverable.
• testing. There are no tests, so CI test integration has no value.
• building. The "go build" command is as simple as could be and runs in the blink of an eye.
• releasing. The project can be trivially installed using the one-line command in the README. Its users are already Go developers; I don't need to tell them to install Go.

The linter check is nice, but it's not important enough to justify this PR.
The version numbering is neat, but again I just don't think it's important enough to complicate the build.

[rsc]

golang-standards/project-layout#117