fix: Adjust OpenLineage DefaultExtractor for RuntimeTaskInstance in Airflow 3

[kacpermuda]

In OpenLineage, we use the DefaultExtractor to extract lineage metadata from Operators that implement OL methods. To determine whether a task succeeded or failed, we rely on ti.state here.

I think we should get rid of that dependency on airflow code model. (EDIT: Missing state attr in RunTimeTaskInstance in Airflow 3 caused our extractor to fail, but even if state is reinstated to RunTimeTaskInstance, we should still proceed with this PR).

Now, depending on which listener method is called (on_task_instance_running, on_task_instance_success, on_task_instance_failed), we manually propagate the current TaskInstanceState to the OL's ExtractorManager. This change allows us to invoke appropriate Extractor method (extract_on_complete or newly added extract_on_failure). This is a similar approach to what we implemented with custom_run_facets

Until now, users using custom extractors had to manually determine whether the task has failed or completed successfully, using task_instance object. They will still be able to do that as long as the state attr is available. The other way, implemented in this PR, would be to implement this new extractor method (extract_on_failure) so that they don't have to worry about checking the state themselves.

I think adding a new method to the extractor base class is the simplest approach, ensuring we don’t break anything for users with existing custom extractors. IMHO this keeps the transition smooth while maintaining backward compatibility.

---

^ 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.

[kacpermuda]

There is a discussion on Slack and state might get re-added to RunTimeTaskInstance. Will keep this as draft for now, until it clarifies. We should proceed with this PR regardless.