Use only real version names, not `next`, for doc version subdirectories under /content

@spzala et al: I'd like to propose that all our doc version subfolders **name the version** they are targeting. That is currently the case except for the special `/docs/next`.

Some **drawbacks of using `/docs/next`** as part of permalinks include the following:

- This muddles analytics
- It makes releasing a new version of the docs a bit more work. For details, see the following threads:
- https://github.com/etcd-io/website/pull/203#discussion_r620307379
- https://github.com/etcd-io/website/pull/203#discussion_r618467132
- In my opinion, it can confuse site users as explained next:
Let's suppose that we just released v3.5 docs, under the current scheme we'd already have a `/docs/next` even though there are no v3.6.x-DRAFT docs. Under the new scheme we can either, not create v3.6 until we have v3.6 docs, or we can immediately create the branch but mark it as draft and not publish it (until we have actual v3.6 specific changes).

Some advantages of using only a version name for doc-version subfolders:

- We can have more than one "next". For example, etcd currently has v3.5 and v4.0 under development.

We can, of course, keep `/docs/next` as a virtual path that is redirected to the/a "next" release of the docs.

Thoughts?

Related:
- Changing "Next" to "Upcoming version" #220 -- though that issue concerns the displayed name, not permalink segment names.
- vX.Y.Z doc pages with links into GitHub should link to vX.Y.Z not master #147

Following, #336, we'll need to consider the impact (and possible improvements) to the `Makefile`.

/cc @nate-double-u