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]

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

[Scienfitz]

is this accurate? train_y for desirability should be the scalarized desirability and not the single targets?

[Scienfitz]

also why is _train_y and _train_x of different type?

[AdrianSosic]

is this accurate? train_y for desirability should be the scalarized desirability and not the single targets?

Depends on what is the intended use of the properties. So far, I just introduced private properties in the way they are needed. train_y is currently only needed for the Pareto ref point computation. What do you think, is this OK?

[AdrianSosic]

also why is _train_y and _train_x of different type?

Same answer: I just extracted the properties exactly in the way they are needed for the specific context

[Scienfitz]

right, one the one hand it makes sense(everything is correct) but breaking the usual tandem between (train_x/y) also seems weird
But given that, I don't see reason to require action, so feel free to resolve