Move readme installers table

[dNechita]

PR Description

Since the README page serves as a landing page for many users looking for a stable installer for their chosen OS, replace the table listing the latest installers (which may not be stable) with tables of officially released installers.

Move the table with the latest installers to a separate .md file, as it remains useful, particularly for developers.

PR Type

• Bug fix (a change that fixes an issue)
• New feature (a change that adds new functionality)
• Breaking change (a change that affects other repos or cause CIs to fail)

PR Checklist

• I have conducted a self-review of my own code changes
• I have commented new code, particulary complex or unclear areas
• I have checked that I did not intoduced new warnings or errors (CI output)
• I have checked that components that use libiio did not get broken
• I have updated the documentation accordingly (GitHub Pages, READMEs, etc)

[rgetz]

I don't think you need previous releases in the readme - only the latest.

[rgetz]

And there likely needs to be some introduction in the developer's readme. Something like:

# libiio - Active Development Overview

**libiio** is under active development, with continuous improvements, bug fixes, and new features added frequently. The `main` branch represents the development of **libiio v1.0**, which introduces a **brand-new API** that is **incompatible with libiio v0.25 and earlier**. This new API reflects significant architectural changes and improvements designed to enhance performance, flexibility, and usability.

## Nightly Builds (Developer Use Only)

To support developers contributing to or testing the experimental features of libiio v1.0 (which encompasses all code on the `main` branch at present), we provide **nightly builds**. These are automated, pre-release versions generated daily from the latest changes in the repository.

These nightly builds are intended **exclusively for development and testing purposes**.  
**End users should avoid using nightly builds in production**, as they may include unstable, incomplete, or breaking changes that could negatively impact performance or functionality.

### Why Use Nightly Builds?

Using nightly builds allows developers to:

- Test and verify new features before they are officially released.
- Identify bugs and regressions early in the development cycle.
- Provide feedback to help shape the final release of libiio v1.0.

### Reporting Issues

If you encounter any bugs or issues while using nightly builds, we encourage you to report them on the [issue tracker](https://github.com/analogdevicesinc/libiio/issues). Early feedback is critical to ensuring the stability and reliability of future releases.

Thank you for contributing to the development of libiio!