feat: trim dependencies

[MrDwarf7]

Summary

Refactoring section

• Removes the requirement for both cfg-if and rand, preferring the use of (already available) cfg decorator for relevant function(s).
• Single branch logic in erase_handler.rs that was originally double-nested behind macro checks is now a single flat function call.
• install_handler.rs now handles the multiple repeat calls with the same Err returns via an inline async closure.
• The large stack of Command::new(..) calls for git actions are now handled in the remote_checks(..) function, which has also had a #[rustfmt::skip] macro applied to it to lessen the effect of large method chaining that's mostly non-relevant to understand the function call use-case.

Cargo section

• Aforementioned removal of deps.
• Improved readability for Cargo.toml by using the standard syntax that almost all Rust projects use for declaring dependencies.
• Removed entirely redundant optional = false clauses from Cargo.toml
• Benchmarked difference on binary size and compilation time using [profile.<profile>.package."*"] and came to the conclusion that it's a marginal improvement to provide correct build instructions for project's dependencies - These each align with debug, release, and your custom one of optimized (for size).
• Moved [[bin]] block to top so other Rust developers can easily locate the required bin file, binstall calls remain at the bottom as they're unlikely to need to be changed or sought after.

Benefits

• Lower binary size - we're now at 5.7M on the optimized profile.
• Due to the changes in hotfix/perf(#331): removes padding on list-remote output #333 + the package opts, output feels smoother (I assume due to less buffering happening during the sys-call/request).

[MrDwarf7]

Also to note - Having read through the documentation for cfg-if each item in the if-else chains are cumulative, which means ones that opted in earlier, are then opted out. It's just to expand multiple sets of #[cfg(...)] or #[cfg_attr(..)]. It would shine in say, a macro/derive-macro library. Definitely isn't something that's needed here. I assume its primary purpose is to slim down the dozens of stacked-marco-sets in the std lol.

[MrDwarf7]

I also plan on submitting some changes that; for the most part, should allow removing a large portion of the install_handler::handle_building_from_source section and also make dispatching a lot easier to manage inside of the code (also high potential to dramatically speed up some of the ops too, but we will see).

[MrDwarf7]

If there's anything else in this one you're wanting to revise @MordechaiHadad , please let me know.
In order to do 'full' testing I'll need to either borrow a Windows machine or set up a VM. You got a Windows machine sitting around for easy testing?