Added filter_range parameter that allows to filter answers with similar start/end indices

[julian-risch]

Design choices
Current question answering predictions contain (near-)duplicates. To ensure a variety of answer options coming from different text positions, this PR introduces a filtering step during the generation of predictions. To control the filtering, there is now an integer filter_range class variable for the class QuestionAnsweringHead. It is applied in the method get_top_candidates.
The default behavior is unchanged and corresponds to filter_range set to -1 (or smaller). Setting the parameter filter_range to 0 removes exact duplicates (same start or end index). Setting the parameter filter_range to any larger value consider answers with similar start or end index as duplicates, e.g., filter_range=5 considers the two answers with start_idx 4 and start_idx 9 as duplicates.

Tests added
test_duplicate_answer_filtering() tests whether there are no two generated answers with the same start or end index.
test_no_duplicate_answer_filtering() tests whether the default behavior is unchanged so that the answers contain duplicates.
test_range_duplicate_answer_filtering() tests whether filter_range = 5 leads to answers with a distance between start indices or end_indices of at least 6.

Limitations
If filter_range is to large (e.g., as large as the number of tokens in the given context) only one answer will be generated.
The similarity of answers is solely defined based on their start and end indices and does not consider similar answer texts with different indices as duplicates.

Future enhancements
Take into account textual similarity rather than only the indices. For example, compare exact words instead of start and end indices. For more advanced solutions, one could use locality-sensitive hash functions on the text of the generated answers and define a threshold of accepted hash distance.

Closes #667

[Timoeller]

Looking good already, lets discuss the proposed changes.

[julian-risch]

As discussed, I removed the example, used fixtures to speed up the CI, and renamed the parameter.

[Timoeller]

Thanks for the improvements. I actually looked a bit deeper into the testing and found potential for improvement.

[julian-risch]

The tests now check for the exact start and end indices so that they are more explicit.
The reason why the no_dupliacte_answer_filtering() test passed is because answers only need to have the same start indices OR the same end indices to count as duplicates here. The current method in the PredictionHead checks for the same start AND the same end indices to filter out duplicates.

[Timoeller]

LGTM