feat: Change outputs of AnswerExactMatchEvaluator

[silvanocerza]

Proposed Changes:

Standardize outputs with other evaluators.
This PR also adds a new test with more complex data.

How did you test it?

I ran tests locally.

Notes for the reviewer

This decision stems from this discussion.

I ignored the release notes as this has still not been released and the PR that added this Component already has release notes.

Checklist

• I have read the contributors guidelines and the code of conduct
• I have updated the related issue with new insights and changes
• I added unit tests and updated the docstrings
• I've used one of the conventional commit types for my PR title: fix:, feat:, build:, chore:, ci:, docs:, style:, refactor:, perf:, test:.
• I documented my code
• I ran pre-commit hooks and fixed any issue

[coveralls]

Pull Request Test Coverage Report for Build 8377370259

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 34 unchanged lines in 3 files lost coverage.
• Overall coverage increased (+0.02%) to 89.282%

---

Files with Coverage Reduction	New Missed Lines	%
components/generators/chat/hugging_face_tgi.py	5	94.79%
components/generators/hugging_face_local.py	6	91.89%
core/pipeline/pipeline.py	23	93.7%

Totals
Change from base Build 8362383368:	0.02%
Covered Lines:	5423
Relevant Lines:	6074

---

💛 - Coveralls

[julian-risch]

I disagree with Changes scores to return the number of matches per question. It differs from the semantics we had in the past for ExactMatch in Haystack and for the use cases we so far support.
If there are multiple answers predicted for one query, they are top k answer candidates in a specific order and we don't aim to cover multiple ground truth questions with them.
Multiple ground truth answers can come from annotations with slightly different punctuation etc. For the users, there is no additional value if the predicted answers for one query contain more than one ground truth answer. Let's leave the metric as is.

[julian-risch]

LGTM! 👍