Add instructions on how to avoid accidental airflow upgrade/downgrade

[potiuk]

Some of our users raised issues that when extending the image, airflow suddenly started reporting problem with database versions and migration not aplied or out-of-sync. This almost always turns out to be a dependency conflict, that leads to automated downgrate or upgrade of installed airflow version. This is - obviously - undesired (you should be upgrading airflow consciously rather than accidentally). However there is no way to do it implicitly - pip might decide to upgrade or downgrade airflow as it sees fit. From the point of view - airflow is just one of the packages and has no special meaning.

The only way to "keep" airflow version is to specify it together with other requirements, pinned to the specific version. This PR updates our examples to do this and explains why airflow is added there.

There is - of course - another risk that the user will forget to update the version of airflow when they upgrade, however, sinc this is explicit action performed during image extension, it is much easier to diagnose and notice. We also warn the users that they should upgrade when airflow is upgraded.

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[potiuk]

This is a doc-only change - updating our examples of docs extending and customising. I think it might be worthwile to cherry-pick it to 2.6.0, as it should help our users to avoid surprising upgrades/downgrade of airflow when they are adding conflicting dependencies. This was a recurring pattern in quite a number of Slack threads and github issues, the problem is that pip treats airflow as "just another python package" and when user installs conflicting dependencies, it will downgrade or upgrade airflow without asking (which is of course rather disastrous). And it especially annoying for automated CI pipelines.

This change updates our examples where requirements are added to also include apache-airflow==<version> in their requirements when they are adding them - this will keep airflow in the version that was there originally, and fail such installation with a conflict informatiion rather than downgrading/upgrading airflow silently.

[potiuk]

cc: @ephraimbuddy -> while preparing my presentation about dependencies, I noticed this one has not been merged to 2.6.0 (Even though it has been marked as such), so I moved it to 2.6.2 (I have one more follow-up after that).