Add searching URL support

[FireController1847]

Replacing my old PR #806 after the change to a monorepo. See that PR for more details. Here's the description form it:

---

Currently, if you want to install an unlisted project to the launcher, you need to manually download the associated file and perform a manual installation. The major issue here is that you can't enable syncing (for modpacks), nor can you update it. This is due to the .mrpack format appearing to be completely independent from the Modrinth site; it doesn't store a ProjectID or a VersionID. This PR aims to resolve these issues.

The functionality I'm proposing is similar to what you'd experience on the Technic Launcher. There, you paste the URL into their search field, and the pack appears as the only search result. As such, this implementation should feel like a natural transition for those familiar with that methodology. Additionally, it addresses any complications that might arise from other solutions and would require the least amount of maintenance effort moving forward.

The only hiccup I ran into was a mismatch between the data structures of a Search Result Model and a Project Model. In the future, it might be useful to consider augmenting the search API to allow for non-indexed results when a specific slug is given, but that's a topic better suited for discussion outside of this PR.

Here's a breakdown of the current workflow:

• Check if the search term is a URL. If it's not, skip the section entirely.
• If it is a URL, but it does not match our required conditions (it must be on the modrinth.com domain and use the appropriate project type), then return zero results.
• Parse the project slug out of the URL and make a request to the API endpoint /project/[slug]
  • To fix a missing 'author' field, make a request to /project/[slug]/members
• Check if the results exist; if not, return zero results.
• Check if the returned project matches the project type; if not, return zero results.
  • Prevents an edge case where the project type and url may be the same, but the project is not that type. For example, /mod/the-fv-pack on the mods tab would work, since it matches the second check (project type tab = mod, url = mod, so it requests /project/the-fv-pack). This check prevents that.
• Convert the Project Model to a Search Result Model.
• Return the results with the project as the only hit.

I recognize that the code might not be optimal, but it is functionally effective. I'm open to any constructive suggestions and willing to make changes as necessary. A video is attached below to demonstrate the new functionality, and a video showing the issue with the old functionality.

9utDqwCoLE.mp4

5mke59xYyq.mp4

[Norbiros]

Suggested change

	potentialUrl.hostname.indexOf('modrinth.com') != -1 &&
	potentialUrl.href.indexOf(`/${projectType.value}/`) != -1
	potentialUrl.hostname.includes('modrinth.com') &&
	potentialUrl.href.includes(`/${projectType.value}/`)

[Norbiros]

Consider using update syntax

[Norbiros]

Make it const

[Geometrically]

I don't like the way this is implemented. It just feels unintuitive and a little jank. Users right now can already install any unlisted pack or mod by opening this URL in their browser:

modrinth://mod/aged (this will install the aged modpack).

I think a better way would be a "From URL" option in the instance creation modal. Then, the user could input any URL and it would automagically get all the details (whether it was a CDN link, modrinth project link, modrinth version link, etc).

Since this will probably touch some part of the backend I recommend basing your PR off my launcher-db-overhual branch. It will be merged soon and that way you can ensure you don't have any duplicate work.

Feel free to ping me on discord if you have any questions!

[Geometrically]

See above