Fix inheritance chain in security manager

[vandonr-amz]

ℹ️ the diff is big because I re-unified the various FAB security managers in one class. See #33901 (comment)

---

There is currently a weird situation with the security managers, where the AirflowSecurityManager, which is supposed to be the more generic construct, inherits from FabAirflowSecurityManagerOverride, supposed to be the more specific one. Because of this, FabAirflowSecurityManagerOverride doesn't bear well its name, because it cannot override anything from AirflowSecurityManager since it sits lower on the inheritance tree.

This was done initially to be able to extend functionalities of the Security Manager, while retaining an existing feature which was that users could plug their own security manager inheriting from AirflowSecurityManager (so we couldn't squeeze the FAB one in between because that'd be a breaking change).

The solution I used here is to have an empty shell stay where the AirflowSecurityManager was, just to maintain back-compatibility. That one inherits from FAB Security Manager, which can now sit below the actual AirflowSecurityManager.

This means that users can only override the FAB security manager and not other auth provider's SM but that's ok because this feature is pretty much rendered obsolete by AIP-56. See #33690 (comment)

Joining some class diagrams to help understanding.
Arrows read as "is inherited/implemented by".

current situation:

after:

I had to make the ApplessAirflowSecurityManager inherit from the "FAB" one instead of the generic airflow SM because it had some dependencies there. It's not ideal, and not what we want in a final state, but for now we just want a state that closer to it.
We'll sort that dependency later on.