Refactor

[lpotthast]

Hi, now to the PR I promised. I does a lot of things by now... Let me try to explain most of them (if I remember them all). Note: I incorporated all your last commits since I forked.

• The builder is no longer a build script. Working with them is hard, and in this case, it must not even run automatically, we would actually much rather want to trigger the build on our own.

• Therefore, the repository now hosts two completely separate crates, the builder binary crate and the actual library. Their readmes reflect that.

• One can now cd build and call cargo run to let the builder create or update the library. Use cargo run -- --clean to force package re-downloads.

• The builder not being a build script also makes observability much easier (build scripts usually swallow all output to stdout and require workarounds...).

• The tracing library is now used throughout the builder, revealing what is going on with what data at most times.

• As there is a lot of I/O, I updated the builder to run on a Tokio runtime, using tokio::fs instead of std::fs throughout.

• Each icon package is managed in parallel, with minimum stuff before or after that.

• All packages are now described in code.

• All packages are defined with specific versions. Either by using a git tag or commit hash. This makes the generation much more stable.

• Packages are no longer added as submodules. Working with submodules is hard enough manually, automatically creating and removing them is not that great and not really required.

• Git icon packages are now simply cloned to the /downloads directory, performing a checkout for the expected git tag or commit ref.

• Working with thousands of files puts a lot of strain on many parts of the system (rust-analyzer, IDE, Git, cargo, ...). And of course, generating them all is slow.

• Therefore: All icons are now generated inside a single module, without any module nesting for categories, reducing the amount of files generated to the number of icon packages involved. A build without downloads should take less then 10 seconds.

• Note: It currently generates a few "unused use" warnings. They can be resolved with Allow component decl without use leptos::* in scope leptos-rs/leptos#748

• All categories are appended to the icons base name, making them not overlap. We could(should?) also verify that this does not happen with a different data structure / a bit more code.

• All icons share a feature and component name, making it as easy as possible for any given user to activate and use them.

• This means hat icons are prefixed by their package short name. This also fixes any problems with icons starting with numeric characters.

• Many smaller or larger architectural changes, making programming errors less likely by leveraging the type system a bit more.

• The README.md of the library is generated, including the table of icon packages and their specific version.

• An ICONS.md file is generated, including all icon names from each icon package.

• NOTE: It will always be a breaking change for leptos-icons if any icon-package is updated (version increased or decreased) and that change was itself breaking.
  To reduce version changes for any given user, onw might publish separate crates like leptos-icons-fa, leptos-icons-bs, ...

[Carlosted]

Wow, this is astonishing!

I'm pretty overwhelmed by this pr, but these are all great changes and I will surely merge them shortly.

I was just wondering why you chose the src/module/mod.rs over the src/module.rs convention?

[lpotthast]

Hi, the leptos-component functions i would leave non snake-case, as it is the UI / Leptos default. To the module convention: I think it's more or less a personal preference. Feel free to change anything. I just like the reduced "visual distance between module related files when looking at a file tree". With a mod.rs file, everything belonging to module "x" is contained in directory "x". I think it is a bit cleaner. The file simply be named "mod.rs" is a downside though... If there would be a "x.rs", defining the module, that might be, in a bigger project, be located "further away" the directory. Either way is totally fine :)