Continuous inter-point constraints

[AVHopp]

This PR introduces a first variant of inter-point constraints by using the botorch-provided interface.

Here, an inter-point constraint is a constraint that acts on a full batch instead of a single recommendation. If we think of a batch recommendation of a matrix with shape batches x features, then our previous constraints would be row-wise, while these constraints allow mixed constraints across both dimensions.

This PR introduces new classes, and these classes were modeled similar to the already existing classes for continuous constraints. Some things had to be changed though resp. we need to aware:

1. Most importantly, the way of sampling points from a polytope. The reason is that get_polytope_samples is not made for including inter-point constraints, and hence a workaround was implemented. The workaround basically transforms the space in a one-dimensional space with batches * features many features, and then defines both normal and inter-point constraints over this space (see [Bug] get_polytope_samples fails for inequalities over q-batches and the actual dimension pytorch/botorch#2468). Note that this might interfere with Botorch with cardinality constraint via sampling #301 and that some alignment might be necessary.
2. The constraints in this PR always combines full columns. That is, the constraints $x_1 <=1$ would be interpreted as "the sum of $x_1$ across the whole batch needs to be smaller than 1". This can e.g. be used to limit the usage of resources, like only having 100ml of a substance available for the full batch. Also, different columns can be combined, so having $x_2 + 2*x_3 <=100$ would mean "sum of $x_1$ plus two times the sum of $x_3$ across the batch has to be smaller than 100$.
3. For now, the constraints have only been applied for continuous search spaces. The reason for this is that I want to keep this PR rather short and use it to discuss in general about the design, and to avoid any potential conflicts with Botorch with cardinality constraint via sampling #301 . However, including them in hybrid search spaces should be possible already in this PR. For discrete spaces, this still needs some investigation. So interpret this as just a first step in the direction of more :)

[AVHopp]

Note: This PR is currently on hold for two reasons:

1. There was a misunderstanding between @AdrianSosic and me what "inter-point" constraint actually means, and incorporating the necessary changes might require some more redesign.
2. There is another open PR which currently changes the behavior of get_polytope_samples, and that PR should be merged first.

[Scienfitz]

as mentioned in our call but posting here for documentation / reference: I think its worth exploring whether a design not via deriving from ContinuousLinearConstraint but by adding a simple switching flag to it might be better

[AdrianSosic]

Not yet completely done with the review, but because time is running, here a first batch of comments

[Scienfitz]

interpoint should be its own example file feels just 'drangepappt' for this example

[AVHopp]

Created a new example, please have a look and resolve if happy

[Scienfitz]

is it feasible to keep splittitng the sample function up like that? eg what happens if we have interpoint+cardinality constraints

[Scienfitz]

isnt 'sample_from_polytope' a special case of the new function? If so I think it could be better design if one was contained int he other or one calls the other

[AVHopp]

You are right, I have combined the two functions into a single one and will resolve this comment here once the changes have been pushed- I will keep the other one open for further discussion of the topic.

[Scienfitz]

the new intperpoint flag should be mentioned in the userguide

[AVHopp]

Included a section on that in the userguide, please resolve if you are happy with it.