RFC Bytecode version in releases/--help

Third-party runtimes seem to be sensitive to the version of bytecode emitted, but it is not always obvious what version of Inklecate is needed for that. In a particular downstream situation (https://github.com/y-lohse/inkjs/issues/217) using 0.8.2 results in bytecode that is too new, while 0.8.1 works. In the current state it is easy for an update to break compatibility (to be expected) but the resulting confusion of "which version should I use?" is not good for prospective new users.

I have recommended that downstream mention the most recent known-good version. I also recommend that any other third party implementations do this, although they seem to want to write it off as a "maintenance issue."

Upstream (here), inklecate should probably carry a version stamp. Most software does, so including a line that looks something like:

```
$ mono inklecate.exe -h
the ink compiler (v0.8.2, bytecode 18)
[..]
```

Version scraping can be automated easily, but how to integrate the stamping is something I don't know about (since I don't use the MS IDE.)

`git describe $(git rev-parse HEAD)` will respond with the closest tag, so the usual tagged release works out. Non-release versions end up with names like "sometag~commitsbehind" but usually projects just go with the commit hash `git rev-parse HEAD` for unreleased editions.

I might be able to fiddle a script together to go through recent releases, compile a sample script and check the ink version. The result of that can at least go in to a simple markdown file (doesn't solve the `-h` situation, but does solve discoverability.)

Thoughts?

The issue focuses on inklecate's `-h` output and suggests recording release and bytecode versions in a Markdown file. Start by examining how the compiler's help entry point and releases are assembled; done means users can identify the compiler and bytecode versions, including for released builds.

Written by the indexing model from the issue text.