ci: Add workflows

[shadeMe]

Ported from the haystack repo, with an additional nightly workflow to test against the main branch.

[anakin87]

I am not entirely familiar with the details of the haystack-experimental project, so I would prefer that @masci also take a look.

Some doubts:

• Not sure but some workflows seem outdated/no longer used and should also be removed from haystack (generate_openapi_specs.py).
• In this project, do we need the workflows for documentation?

[shadeMe]

I am not entirely familiar with the details of the haystack-experimental project, so I would prefer that @masci also take a look.

Some doubts:

* Not sure but some workflows seem outdated/no longer used and should also be removed from haystack (`generate_openapi_specs.py`).

* In this project, do we need the workflows for documentation?

• Yeah, I wasn't sure what was still used and what wasn't, so I tried to be conservative in removing them.
• Yes, we do. We still need to figure out how to best deploy the docs, but we need to at least have a way of exposing the API docs of the experimental components to the user - Anything less would impede them from actually trying them out.

[masci]

I would advocate to proceed the other way around, pulling in the workflows we need as we need them rather than cargo-loading Haystack CI and then remove.

[shadeMe]

I've now kept just the bare minimum (linting, testing, publishing) workflows needed to merge PRs and releasing packages.

[masci]

A few questions:

• I initially disabled the issue tracker, to avoid having one more place where to monitor issues (it's already some work moving issues from hasytack to haystack-core-integrations). Do we want to track issues for the experimental package?
• Do we need to use reno for the release notes? A simpler approach might be using the github release generator that relies on PR titles

[shadeMe]

A few questions:

* I initially disabled the issue tracker, to avoid having one more place where to monitor issues (it's already some work moving issues from hasytack to haystack-core-integrations). Do we want to track issues for the experimental package?

* Do we need to use `reno` for the release notes? A simpler approach might be using the github release generator that relies on PR titles

• Ah, I see - didn't notice that the issues were already disabled. I'll remove the templates then (agree that it's better to have all issues in the core repo).
• Fine by me to make things even simpler. I've removed those workflows.