Reagent data structure and recipe resolution refactor

[LucasLMartini]

This is an untested refactor of the reagent data structure and ReagentManager.get_reagents_to_use(), which if functional should speed up recipe resolution by many orders of magnitude, in particular of the most complex recipes. Feel free to ping me in Disc if you wanna discuss this or point any errors, like I said I didn't manage to test this, I couldn't figure out how to run the project in Godot, guess I'm a lamer. My brain-compiler says the function should behave exactly like the original from the outside though! =P

[rilifon]

Hey there! Thanks for the PR! It's a very interesting solution that does solve the complexity of the algorithm, and we appreciate your effort in implementing it. Unfortunately, there are a few problems with it, the major one being it assumes this linear progression of power between reagents and their substitutions. Although this is true at the moment, it doesn't reflect how we are planning to expand the design space of the game, since we soon we'll have a much more diverse matrices of substitutions, some of which might change dynamically based on artifacts and special conditions the player will get in a run. This all will make your solution unviable to use, since this condition makes this problem into a hard classification problem.

But again, we are thankful for the contribution, and this PR was the cataclysm to actually make me refactor the current algorithm and fix another issue that was pending for a while now (#217). I'll be working on both these issues (and hopefully finish it) by the end of the week. I gave you a special role on our discord as "collaborator", giving you access to an exclusive channel in our server, in case you want to discuss this or any other matters. We would love to have more contributions made by you in the future!

In the meantime, since we don't yet have a "How To Contribute Guide" on our repo, a few suggestions for future PRs:

• No need to include commented refactored code, this only clutters files with unnecessary changes. Github serves as version control for this exact reason. In case we need to consult past code, we can check it here.
• Comments shouldn't self-reference the PR or include question/doubts, like "With this refactor, this thing will be implemented" or "I don't know if it passes arrays by copy". Remember that ideally all PRs will be merged as part of a whole project, not as individual snippets of code. And if you have a question, the best approach is to talk to us or any other contributor before sending the PR for approval, it's easier to help out this way. If you feel something like this needs to be mentioned somewhere, keep it at the PR discussion, not actual commits to the repo.
• Try to build the custom Godot, so you can test things! We can help you in case you're having trouble with this. For any non-trivial contributions, like yours was, it's pretty important that you test things out before sending them to us, to lighten the workload on our end.