feat: improved error handling

[justsaft]

This change is aimed to improve the UX of errors from Vib.
To achieve this, Vib now acts more like a compiler, specifically as in collecting as many as possible errors in stdout before exiting, and giving clearer error messages while doing so.

Some help to get the last few nits picked would be very much welcome and appreciated.
This is mainly set to draft because I only had limited time for error path & happy path testing and would like potential bugs I haven’t noticed to be fixed before a release of Vib.

Changes:

• clearer and more explicit printed messages that go along this scheme:
  • Building [ <type of module> ] module <module name> of <submodule> included by <including module>:
• introduced helper function to avoid code duplication
• handling of specific errors to continue collecting errors
• duplicate module name checks
• handles empty plugin name
• handles non-existent Plugin with error message
• renames a bunch of err and error named variables to use an underscore so we can import errors
• adds machinery to control recursive including depth of modules
• changes messages to better tell if a submodule of an include module is being built -> better chance of immediately locating problems

Resolves:

https://discord.com/channels/1023243680829681704/1468666070343618836
Vanilla-OS/custom-image#26
#147

Need ideas for:

• package scope variables at top of core/build.go
• storing every path of every recipe/module Vib encounters -> error printing

[NN708]

Could you rebase this onto main?

[justsaft]

This rebase feels rather dirty I'm not gonna lie. Either way this should bring in all the changes from main.

[NN708]

Thanks for working on this. A rebase is still necessary to maintain a clean, linear commit history. I also suggest splitting the changes into several smaller commits, each focused on a single functional change. This will make the review process much easier and the history more readable.

[NN708]

Why limit this to 1?

[justsaft]

No particular reason other than to test this. Whether or not there are recipes out there that use this or not, we should not restrict this at 1. I'm gonna get back to this in a bit.