Split puppet.rs into a module

[orowith2os]

Previously, everything regarding puppet was in puppet.rs. Now, it's split up into puppet/ so that it's easier to manage and search though.

The API should be the same, save for the enum modifications made.

The modifications to the enums are meant to better reflect their usage, and real-world examples. For example, instead of ViralLicense, it's SameLicense. Instead of Copyleft, it's Permissive.

[orowith2os]

Didn't mean to include some changes here, but w/e.

[orowith2os]

CI is failing due to tests that were failing before my changes.

[Speykious]

Yeah the CI is way too complex for this project, I was wrong to take it from Jon Gjengset... x_x

I'm gonna completely change it once the renderless PR is merged.

[Speykious]

We had a long discussion about this file split on Discord. We couldn't get to understand our differing opinions unfortunately, but in any case I'll sum up why I don't agree to this change:

• In Rust codebases, the tendency is to organize files by behavior and not by type. It has several advantages which I'm listing below and are the reason puppet.rs is this way. It's not always the case as sometimes a struct will have a huge impl block, but that's the exception rather than the norm and it certainly doesn't apply here.
• When someone new to the codebase comes in, every struct that a puppet uses is gonna be in puppet.rs, as opposed to having to jump into a bunch of files to construct the bigger picture in their head. This makes the code much more readable.
• It is not easier to search through. Every decent IDE and code editor has features such as Go To Definition and Go To References, thanks to LSPs. If you want to search for a struct, use that. We shouldn't rely on files to search for structs, we should use files to organize code in general. It's not just structs that should be easy to search, behavior should be too, and we're definitely not having one file per function and per struct, so organizing in terms of behavior is imo the best compromise.
• When adding new features, very often we'll have to implement the same kind of behavior on all kinds of related structs, and puppet.rs applies perfectly to this use-case. For example, a split that I would most definitely accept is putting all the Display impls in their own files.

So yeah, in short, I won't accept this PR. But if you just split the display impls into their own single file I will :)

[orowith2os]

Maybe reopen this so i can just push my changes rather than opening another PR.

[Speykious]

Hm ok

[orowith2os]

Need input on if I should also do a try_from.rs.

[Speykious]

So far the split is good. I think there's no need for a try_from file, there are like 2 small impl blocks for it.

[orowith2os]

You underestimate just how annoyed I can get at code sometimes 😀

[Speykious]

Since this has been hanging around, I've decided to not merge this. Kinda unnecessary at this point. Even for splitting Display I wouldn't do it, it's too much of a standard trait to implement for it to be separated from its struct, and the same can be said of TryFrom. (I know, I changed my opinion since then.)

I'll just let all the puppet structs be in one nice readable file like they always were.