feat(labrinth): Add support for dependencies in search

[IThundxr]

Adds dependencies to the projects index in meilisearch, this will allow you to search for mods depending on a specific mod. This is a continuation of #4105.

This currently does not include support for searching dependencies in the frontend, some work has been done here but i'm not entirely sure how this should be laid out and look like, i think it'll be better for the team to work on implementing that instead.

[Prospector]

I would add each dependency type as a separate array, so like required_dependencies, optional_dependencies, incompatibilities, etc.

[IThundxr]

I would add each dependency type as a separate array, so like required_dependencies, optional_dependencies, incompatibilities, etc.

Went ahead and made it use a map instead, the output of /v3/search looks like the following: https://hst.sh/yaxijigeti.json

[IThundxr]

Actually, you wouldn't be able to filter those with facets, i'll split them into 3 different arrays

[fetchfern]

Would need to be migrated to typesense since we use it for search now

[IThundxr]

Addressed the reviews, and made some additional changes:

• Move dependency lists into their own struct, and create a struct for dependencies which contains the project id and if available the version id
• Formatted dependency as project[:version] in the returned search data (a wildcard can be used in the facet to get all mods that depend on a specific mod, rather than a specific version of a mod), Examples:
  • [["required_dependencies:97h8UxBq*"]] for anything depending on project 97h8UxBq
  • [["required_dependencies:97h8UxBq:grWk3nFR"]] for anything depending on version grWk3nFR from project 97h8UxBq
• Instead of adding to vecs based off type strings, it now uses the enum, had to adjust the DependencyType struct a bit so sqlx would automatically convert the type in the query
• Documented the query, and added a little explainer on what each returned column represents as the names feel a bit confusing

A question i have about the db schema is: dependencies.mod_dependency_id is marked as nullable, but are there any cases in which it'd actually be null? Would be nice if someone could the query below to check, as if it's never going to be null, it would be better to create a migration for that and remove the null checking that is currently needed for it.
SELECT COUNT(*) FROM dependencies WHERE mod_dependency_id IS NULL;