Describe the bug
Searching for more than thirty-eight ingredients using the recipe search APIs (either search or explore) for more than thirty-eight ingredients currently fails.

The reason is that we construct an ingredient match boost based on a power-of-ten and the numbered position of each ingredient within the query (and in fact we double that during exact-match searching).

The search engine (currently opensearch, was elasticsearch) is written in Java and expects the boost to be an floating point value, with a supported value range approximately up to 10e38.

Strictly speaking we don't need to use base-10 here. We need enough numeral-distance between each boost value to disambiguate between exact and partial matches as documented here, but I think we could achieve that in base-4 or something. The question is whether the (already complex) logic to implement that is worthwhile.

If my calculations are correct, using a base-4 representation for the boost value would allow us up to 64 ingredients, and base-3 would allow up to 80.

Alternatively we could simply decide that some arbitrary number of ingredients is a sensible upper limit. Thirty or so seems like it may be reasonable.

To Reproduce
Steps to reproduce the behavior:

1. Visit the homepage.
2. Add thirty eight or more ingredients to include.
3. Click the search button.
4. Find no results / notice an HTTP 500 response from the server.

Expected behavior
Results should be returned based on all query ingredients -- or with an explanatory refinement message if the query omitted some of the ingredients.

Screenshots
N/A