Consider the use of semver tags for builds

[longregen]

TLDR: instead of build-{ci build number}-{short hash}, tag builds as {branch}-{major}.{minor}.{ci build number}-{short hash} to help developer and user productivity. Current release would be master-0.0.10000-777f42b instead of just master-777f42b

From #2732: build tags would benefit greatly from something similar to semantic version or a similar system. It's a given that the development speed in the project is very fast, and that seems to be tied to a concept of "not naming builds as releases". I understand why that would make people think the project is more ready to use than it actually is. Simply saying "it is not ready for anything yet" is a fast and polite answer and a time saver for maintainers and developers.

Having said that, I'd like to propose that the build tagging schema follows some sort of semantic versioning for builds. It's easy to see that a simple indicator like a minor bump for somewhat critical changes, like the gguf merge, graph allocator changes, or new kernels, could make the build version a time saver when working on different branches. For example, if builds with the gguf merge had a v0.1 bump, any build with a v0.0 minor prefix could quickly tell a maintainer that the branch for this build was not merged with the latest master, and users could debug more easily if they realize their models where quantized with an old/buggy version of convert tools (see also #2728). It is also nice for users to feel excited about what new awesomeness might this minor bump bring about.

I believe the change to be fairly small, with just two defines (or even one, just the minor version and a hard-coded zero major) the build system that could get bumped whenever somewhat big changes happen.