feat(Algolia.Api): cache requests

[thecristen]

Summary of changes

Asana Ticket: No ticket

While working on the autocomplete widget I noticed an opportunity for us to cache our requests to the Algolia REST API!

This PR uses our existing RepoCache module to cache the POST requests we make to Algolia, based on two parameters

1. The request body. It's a gnarly string of text looking something like this (yes it's a query for the letter r).

"{\"requests\":[{\"query\":\"r\",\"params\":\"analytics=false&clickAnalytics=true&facetFilters=%5B%5B%5D%5D&facets=%5B%22*%22%5D&hitsPerPage=5\",\"indexName\":\"routes\"},{\"query\":\"r\",\"params\":\"analytics=false&clickAnalytics=true&facetFilters=%5B%5B%5D%5D&facets=%5B%22*%22%5D&hitsPerPage=2\",\"indexName\":\"stops\"},{\"query\":\"r\",\"params\":\"analytics=false&clickAnalytics=true&facetFilters=%5B%5B%22_content_type%3Apage%22%2C%22_content_type%3Asearch_result%22%2C%22_content_type%3Adiversion%22%2C%22_content_type%3Alanding_page%22%2C%22_content_type%3Aperson%22%2C%22_content_type%3Aproject%22%2C%22_content_type%3Aproject_update%22%5D%5D&facets=%5B%22*%22%5D&hitsPerPage=2\",\"indexName\":\"drupal\"}]}"

It'll have different params depending on the type of search (e.g. the request body for searching r in the trip planner will look different as it'll just search for 3 stops instead of 2 stops, 5 routes, and results from the CMS). So the results for one search box is not necessarily cached for use by a different search box in the website -- that'll only happen if both perform exactly the same query with exactly the same sets of parameters.
2. The Algolia configuration - this is just a struct that captures the API keys in use. I figure caching should only be valid if the request is made with the same API keys.

---

General checks

• Are the changes organized into self-contained commits with descriptive and well-formatted commit messages? This is a good practice that can facilitate easier reviews.
• Testing. Do the changes include relevant passing updates to tests? This includes updating screenshots. Preferably tests are run locally to verify that there are no test failures created by these changes, before opening a PR.
• Tech debt. Have you checked for tech debt you can address in the area you're working in? This can be a good time to address small issues, or create Asana tickets for larger issues.

[kotva006]

LGTM