Add pre-release build validation to ensure stable releases

[g000sha256]

Problem

The project uses special commits with version bumps. Developers rely on these commits as release markers to update their projects and build a new version. However, sometimes these revisions don't compile on certain platforms.

For example, the latest release 1.8.56 fails to build for macOS (I didn't check other platforms). The TDLib build process is time-consuming, and failed builds waste both developers' time and money.

Proposed solutions

To make TDLib releases stable and save developers time and money:

• Add automated build validation - run builds locally or remotely (for example, via GitHub Actions) for major platforms (Android, iOS, macOS, Linux, Windows, etc.) before committing a new version.
• Quick patch releases - if a version commit has build issues, immediately release a new patch version once fixed.

[levlam]

Add automated build validation - run builds locally or remotely

This is generally good, but there are dozens different popular versions of C++ compilers, many ways to build TDLib and many supported platforms. So, it is either will cover only minor amount of cases, will require a very big cluster for testing, or will take days to complete. Nevertheless, it is still a nice thing to have, although not a silver bullet.

Developers rely on these commits as release markers to update their projects and build a new version. Quick patch releases - if a version commit has build issues, immediately release a new patch version once fixed.

Increasing patch version is also a good thing, but this will require different versioning scheme. Currently, if the code is pushed to Github then something important was changed. Therefore, it is better to build a new version each time the code is updated instead of using commits with specific commit message.

[g000sha256]

The latest commit also doesn't guarantee stability. Without automated validation or stable release markers, how should developers identify which commits are safe to build from?

I understand the concerns about testing complexity, but I think automated validation could be more practical than it seems:

• The build instructions don't specify exact versions of tools, which means CI can use the latest stable versions. This actually eliminates the "dozens of compiler versions" factor - just test with current toolchains.
• We don't need to test every possible configuration. A basic CI pipeline covering the main platforms (Android, iOS, macOS, Linux, Windows) would catch most issues. I assume you already test C/C++ builds locally before pushing?) Adding a few more language bindings wouldn't drastically increase complexity.
• From my experience, builds take 15 minutes to 1 hour, depending on the platform. Running them in parallel wouldn't take much time, as GitHub Actions provides concurrent runners, allowing the whole pipeline to complete in about an hour.
• Common issues (missing headers, API changes, syntax errors) typically affect multiple platforms similarly. Even a small set of automated builds would catch the majority of problems before they reach version commits.

This doesn't have to be perfect or cover every edge case - even basic validation would significantly improve reliability for downstream developers.