Add monthly manual versioning (major.minor VERSION + release workflow)

[gggdttt]

What

Adds an on-demand (roughly monthly) versioning scheme for BCQuality content —
not a tag on every commit.

• VERSION — a major.minor value (starts at 1.0).
• release-version.yml — manual workflow_dispatch that tags the current
  main commit as v{VERSION} and refuses to re-tag an existing version.

Semantics

• The minor is a monotonic counter: only ever incremented, never
  reset — even across a major bump. Bump it for the usual ~monthly content
  release; bump the major for a breaking change but keep the minor climbing.
• Because the minor is never reused, it uniquely identifies a release.

Why

The PRReviewAgent (microsoft/BC-ALAgents) composes an X.Y.Z version where Z
is the BCQuality release the reviewer used. It pins this VERSION in its
bcquality.config.yaml and uses this minor as Z — the never-reset minor
keeps Z unique.

Consumed by

• Adopt X.Y.Z version scheme with floating latest tag BC-ALAgents#15 — reads this version and uses the minor as Z in the
  engine's X.Y.Z version.

[github-actions]

👋 Heads up @gggdttt — and cc maintainers — this PR introduces new top-level entries that aren't part of BCQuality's known repository structure:

• 📄 VERSION (new top-level file)

This isn't a block — just a flag. 🚩 New top-level folders and files are usually unintended (a stray export, a tool's scratch dir, or content that meant to land inside an existing layer like /community/knowledge/). BCQuality keeps a deliberately small root: .github/, community/, custom/, microsoft/, skills/, and tools/, plus a handful of root docs.

If this was intentional and the new entry genuinely belongs at the repo root, a maintainer can review and merge as normal — no action needed beyond a quick sanity check. If it wasn't, please move the content into the right existing layer (or drop it) and push an update. 🙏

A maintainer will take a look before merging.