v0.3.0 will be a CLI instead of proc-macro

[Pistonight]

This is both a decision made after #7 and from using the proc-macro ways for the past week

I liked the proc-macro provided an inline way of documenting the dependencies, right in lib.rs. However, the disadvantage/hacks are too cumbersome when actually using it:

1. There is an unsettled conversation on if proc-macros should receive the content of non-inline modules (see Tracking issue for procedural macros and "hygiene 2.0" rust-lang/rust#54727 ). It's not clear what will be the future
2. rust-analyzer integration is lacking. Although it might be possible for rust-analyzer to implement something along the lines of "look at the existing import style and suggestion closest style to import", that's a very complicated feature (because it sounds easy to a human), so it's not reasonable to expect that to be added. As a result, the imports added from accepting rust-analyzer's suggestion won't get analyzed by the layer stuff
3. There's no actual way to completely prevent violations with just proc-macros. You have to also rely on code reviews and we know that's never reliable

Therefore, v0.3.0 will be a complete rewrite to a CLI tool:

1. a Layerfile.toml will be used to declare the dependencies rather than inline in the code. We can do something along the lines of parsing comments, but that's too much of a hack - maybe we can try non-attribute macros in the future (since attribute macros are unstable)
2. Layers will be strictly enforced by running a check that split the crate into 2 parts: the layer being checked and its dependencies, then try to build the test crate. This check will done for every layer. This also means you cannot import from a transitive dependency
   • Things like pub(crate) and impl will no longer work across layers in this case, but you can loosen the restriction in the config to allow some dependency to be in the same crate when checked. However this also means transitive dependency won't get caught
3. There will probably be issues with crate name in macro expansion. More details when it's released

Note: I have also considered static checks. However, because dependency can be generated by macros, that's simply not possible

[Pistonight]

If your crate has macros or proc-macros whose output contains the name of your crate:

1. For macros defined in the same crate, using $crate should work as expected, unless you are specifying a path that violates the layer rules.

2. For macros defined in a different crate, simply use the crate name, as it's impossible to detect if the crate is renamed or not when external user uses it

3. For procedural macros that are only meant to be used in your crate, use the crate name directly, and add this to lib.rs of the main crate:

   use extern crate self as my_crate_name;

   This will make it so you can refer to the current crate as my_crate_name

4. Finally, for procedural macros that are meant to be used by users of your library, the method above will work unless your user renamed the crate in their Cargo.toml.

   In this case, if you really want to support it, you have to detect the renamed crate using something like proc-macro-crate. However, this will NOT work in layer checking. During layer checking, you need to use crate or the crate name directly to import to make sure it's pulling the right copy of the type/trait.

   To work around this, add a feature to the proc macro crate that can toggle the behavior, then enable the feature for layer checking, for example:

   # in your proc-macro crate's Cargo.toml
   [features]
   __layer-check = []
   
   # in your main crate's Cargo.toml
   [dependencies]
   my_proc_macro_crate = { path = "../my_proc_macro_crate" }
   
   [features]
   __layer-check = ["my_proc_macro_crate/__layer-check"]

   Then run layered-crate -- check --lib --features __layer-check

5. All macro output should still follow the same layer rules