Version numbers

In camp/config.hpp.in, version numbers are generated like so:

```
#define CAMP_VERSION_MAJOR @camp_VERSION_MAJOR@
#define CAMP_VERSION_MINOR @camp_VERSION_MINOR@
#define CAMP_VERSION_PATCH @camp_VERSION_PATCH@

#define CAMP_VERSION \
(CAMP_VERSION_MAJOR * 1000000) + (CAMP_VERSION_MINOR * 1000) \
+ (CAMP_VERSION_PATCH)
```

In a concrete example:

```
#define CAMP_VERSION_MAJOR 2025
#define CAMP_VERSION_MINOR 12
#define CAMP_VERSION_PATCH 0
```

This results in CAMP_VERSION being 2025012000, which looks really weird and isn't easy to process mentally. If we took out one order of magnitude for CAMP_VERSION_MAJOR, it would be better (e.g. 202512000). I'd like it even better if it looked like 20251200 or 20260700. To get that, we'd have to change the definition of CAMP_VERSION to the following:

```
#define CAMP_VERSION \
(CAMP_VERSION_MAJOR * 10000) + (CAMP_VERSION_MINOR * 100) \
+ (CAMP_VERSION_PATCH)
```

The biggest downside would be that you couldn't use code like the following because the version number would actually decrease from 2026.07.0 to 2026.07.1 or anything newer:

```
#if CAMP_VERSION >= 20260701
m_async_resource.wait_for(m_wait_for_event);
#else
m_async_resource.wait_for(&m_wait_for_event);
#endif
```

Start with camp/config.hpp.in and inspect how CAMP_VERSION is consumed in preprocessor conditionals, including the CAMP_VERSION comparison shown in the issue. Determine the compatibility implications of changing the encoding, then establish an agreed version scheme and update the affected definition and usage guidance once the project decides how older comparisons should work.

Written by the indexing model from the issue text.