Connect `filter` to rejection mechanisms like `fc.pre` does

[dubzzz]

💡 Idea

Provide a built-in way to work with infinite loops in filter.

Motivation

On its own filter might easily lead to infinite loops when predicates are wrongly defined. Contrary to fc.pre it does not stop itself from running when it reached to many tries to generate something.

As reported in https://github.com/dubzzz/fast-check/discussions/4659, it could be great to have something for filter.

Example

Here are some possible options that came to my mind:

• Option 1: Provide something like buildStoppeable.
• Option 2: Connect it directly in Arbitrary.prototype.filter (we have to measure the performance cost if we go in that direction).

Whatever the option it could be great to have the following:

• Same policy as fc.pre: it should rely on the very same configuration (to be confirmed).
• Should not destroy performance
• Should not tied arbitraries with properties too deeply
• Should be reported properly