docs: Update documented versioning scheme to right-shifted semver (#1990)

<!-- .github/pull_request_template.md -->

## 📌 Description

Based on discussion with @yzh119 and others, we're planning to follow
the vLLM "right-shifted" versioning scheme. This PR updates the docs to
reflect that.

## 🔍 Related Issues

Previously we said we would follow Semantic Versioning (see #1553).
However, we recently re-considered this approach, to better match the
conventions followed by vLLM and PyTorch.

## 🚀 Pull Request Checklist

Thank you for contributing to FlashInfer! Before we review your pull
request, please make sure the following items are complete.

### ✅ Pre-commit Checks

- [x] I have installed `pre-commit` by running `pip install pre-commit`
(or used your preferred method).
- [x] I have installed the hooks with `pre-commit install`.
- [x] I have run the hooks manually with `pre-commit run --all-files`
and fixed any reported issues.

> If you are unsure about how to set up `pre-commit`, see [the
pre-commit documentation](https://pre-commit.com/).

## 🧪 Tests

Docs only, so no new tests are needed. Did not verify passing unit
tests.

- [x] Tests have been added or updated as needed.
- [ ] All tests are passing (`unittest`, etc.).

## Reviewer Notes

<!-- Optional: anything you'd like reviewers to focus on, concerns, etc.
-->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Documentation**
* Updated release versioning scheme to a "right-shifted" format
(major.minor.patch[.post1]) with an optional post-release suffix for
expedited follow-up releases.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Author: sricketts

CONTRIBUTING.md

@@ -36,12 +36,11 @@ Code Contribution Procedure
 
 # Release Versioning
 
-When incrementing a version and creating a release, follow [Semantic Versioning](https://packaging.python.org/en/latest/discussions/versioning/) (`major.minor.patch`) [^1]. In particular:
+When incrementing a version and creating a release, follow a "right-shifted" versioning scheme similar to [vLLM Release Versioning](https://github.com/vllm-project/vllm/blob/main/RELEASE.md) (`major.minor.patch[.post1]`) [^1]. In particular:
 
-* major increment signals incompatible API changes
-* minor increment signals added functionality that is backwards-compatible (e.g. new kernels, new SM support, etc)
-* patch increment signals backwards-compatible bug fixes (both for functional and performance issues)
+* _major_ increment signals architectural milestone and/or when incompatible API changes are made, similar to PyTorch 2.0.
+* _minor_ increment signals significant backwards-compatible new features
+* _patch_ increment signals small backwards-compatible features (e.g. new kernels, new SM support, etc) and backwards-compatible bug fixes
+* _post1_ is an optional suffix for a quick follow up release with just backwards-compatible bug fixes
 
-Optionally, use post-releases (e.g., `X.Y.Z.post1`) for minor changes, like a documentation change.
-
-[^1]: We have not followed this strictly through v0.2.14.post1. But after v0.2.14.post1, the versioning should follow SemVer.
+[^1]: We have not followed this strictly through v0.4.0. But after v0.4.0, the versioning should follow this "right-shifted" versioning scheme.