Add Inequality Constraints to SEBO

[CompRhys]

Following pytorch/botorch#2588 being merged there is now no reason to stop people using inequality constraints with SEBO. This PR removes the ValueError check and adjusts the tests accordingly.

Connected to #2790

[Balandat]

Thanks - if you don't mind fixing that one small linter nit the rest lgtm!

[Balandat]

Actually there are a couple of other lint failures as well: https://github.com/facebook/Ax/actions/runs/11468956837/job/31951921724?pr=2938

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.65%. Comparing base (a85c7ee) to head (a560e9f).
Report is 50 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2938   +/-   ##
=======================================
  Coverage   95.64%   95.65%           
=======================================
  Files         486      486           
  Lines       48871    48879    +8     
=======================================
+ Hits        46745    46753    +8     
  Misses       2126     2126           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[CompRhys]

Merged the changes from #2935 and then fixed the flake8 complaints. I just went ahead and fixed everything flake8 complained about in the repo rather than just the files I touched.

So used to relying on pre-commit that I always forget to lint manually when there's not a hook.

[facebook-github-bot]

@Balandat has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[Balandat]

Actually, you will want to make sure that you take into account the inequality constraints when in get_batch_initial_conditions() when you call this inside _optimize_with_homotopy()

[CompRhys]

The naive solution would be to set it to None if inequality constraints are given which would then cause it to default to the behavior in botorch's gen_batch_initial_conditions. Would that be sufficient to be an acceptable solution here? Whether this is okay depends on how important the additional sampling around the pareto front is to performance (ping @dme65 as this was changed in the last few days).

Adding something more involved would require a bit more thought.