Add multiple recipe tree management and batch manipulation

[ICaxapI]

Enhance recipe tree functionality with support for multiple trees, allowing addition, removal, and selection. Add combinable costs and progression for aggregated handling. Introduce new tooltips for advanced batch adjustments with Ctrl and Alt.

To add new recipe trees, you need to press the add recipe button in the new recipe while holding down the Shift key.

[emilyploszaj]

Sorry to point you to a discussion forum like Discord, but there has been notable work on features overlapping these behaviors there which would be a good indicator to inform how design should look. I do not have time to thoroughly review this code at the moment, but I will say an implementation already exists that takes many different design decisions. Could you justify any changes you've made to the user experience (visuals, keybinds, tooltips, positioning, functionality) in your implementation?

[ICaxapI]

Hi! I read CONTRIBUTING.md, but I couldn't find a Discord link for syncing the functionality/disign.
This FR is largely a response to a request for multi-tree functionality. You can read the original request there, and this PR mostly fulfills that request.
This PR only adds functionality for displaying and counting materials for multiple items at once, accounting for cross-materials and recipes. Here, I've only added a bind for pressing the tree display button with shift, which will add the selected item to the current tree in memory and display two trees at once. (This picture from another PR, there I slightly improved the visuals and now it looks like this. If my PR is in demand, I could update it so that it looks correct and more polished, just give me a sign :) ) ->

In another PR, I also added saving/renaming/deleting tree sets to selectable keybinds, which will allow me to store multiple recipe sets at once and quickly switch between them (in a separate page or subpanel). I reused one class from that PR for display, so it was in my PR, but I can transfer all this extended functionality for [multi-trees only] to this PR. I didn't want to do this because I would have given credit to the author of the bookmark PR for the class I reused.

If there are any specific areas that need improvement (for example, in the design), please describe them. I would like to see this functionality in the official EMI.

[ICaxapI]

After three weeks of testing, I can say it works perfectly. I've already used this patch to plan and craft huge factories with multi-block machines and complex, multi-tiered recipes. Synthetic favorite lists reached halfway down the second page, and everything worked perfectly, including saving the factory plan between sessions.

[Starmania]

This is not fluent french ("racine" for "root" does match, but feels a bit off)

[Starmania]

Here are some better alternatives imo

• objets principaux
• objets finaux

[Zeyrox902]

I’ve identified a few implementation errors:

• Leftover handling: If an item is marked as a leftover for one recipe, it isn't being reused for others.
• Root items: Similarly, a leftover item cannot currently be used as a root item.

UI Suggestion: When the total cost is very high, the interface zooms out significantly to fit everything on screen, making it hard to read. Implementing a "break" for large scales would be a great improvement, though it might be outside the scope of this PR.

Screenshots for context, illustrating the second point:

[ICaxapI]

I’ve identified a few implementation errors:

• Leftover handling: If an item is marked as a leftover for one recipe, it isn't being reused for others.

Yes, it's true leftovers don't count as ingredients for crafting adjacent trees. I actually considered this during the implementation and thought it would be more convenient. But now I realize I haven't encountered a single issue in the game where this was truly useful and didn't become annoying. It's actually a very easy fix.

• Root items: Similarly, a leftover item cannot currently be used as a root item.

If you mean that if one root recipe contains a final element from another root recipe, it won't be calculated correctly, then this is the same issue as above. I'll fix it in the next commit. Thank you for your attention.

[ICaxapI]

UI Suggestion: When the total cost is very high, the interface zooms out significantly to fit everything on screen, making it hard to read. Implementing a "break" for large scales would be a great improvement, though it might be outside the scope of this PR.

Yep, with multitrees this line can get really long. Maybe we should wrap elements to the next line when the number of elements exceeds a certain limit?