Acquisition function builder

[AdrianSosic]

This PR refactors the translation of BayBE acquisition functions into BoTorch acquisition functions, adopting concepts from the builder software pattern.

Rationale / Goals / Problems Addressed:

• No more monolithic spaghetti logic --> instead small isolated methods per attribute/concept
• No more partially overlapping if-conditions (which were the source of many bugs in the past)
• No more "string-based" logic
• Clear overview of existing arguments and (validation of) their types via the BotorchAcquisitionArgs class
• No more need to think about where/when to compute potentially costly intermediate quantities that are only needed in some cases --> (cached) properties instead

[AdrianSosic]

@Scienfitz: definitely curious about your feedback. I think the current draft is already substantially clearer and less error-prone that what we had before. The way I went about this is to think about the main pain points and see what architecture could solve them all, that's how I ended up with the design. However, there might still be parts that can be done in a very different/better way, or perhaps there is an even cleverer design to start with. Let me hear your thoughts.

[Scienfitz]

this has the potential to break things badly, hence it would be a great use case for applying the benchmarks comparisons

if not, at the very least we need to check 2-3 curve or example whether they've changed. Whata bout directi arylation, michaelewicz and bandit to cover several distinct things?

[AdrianSosic]

I agree, this one can have huge implications. The hope is that this is more or less the last time that we need to worry as much about breaking things as we did in the past. But yes, we should definitely run some examples before we merge, ideally both of us

[Scienfitz]

seems fine, as discussed in chat

[Scienfitz]

I def support the idea of this, do you want to move it to production?