Avoid mod nesting with identical name.

[yusufraji]

In #20 where we've introduced clippy, we have a clippy::module_inception warning.

warning: module has the same name as its containing module
 --> src/patch/mod.rs:5:1
  |
5 | pub mod patch;
  | ^^^^^^^^^^^^^^
  |
  = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.97.0/index.html#module_inception
  = note: `#[warn(clippy::module_inception)]` on by default

We have allowed this warning in the PR, but it has to be fixed by either:

1. re-exporting patch::patch::* as patch::*, or
2. renaming the module

[yusufraji]

Example:
Patch is currently imported through patchparser::patch::patch::Patch. Preferred would be patchparser::patch::Patch.

[pflanze]

The best solution is probably to split off the files outside the patch-parser/src/patch/ directory out of the patch-parser crate into separate crates. Then move the contents of patch-parser/src/patch/ one level up.

I haven't looked through it deely, though. We might want to look at it together.

[pflanze]

Here are the possible choices I've been going through in my head:

• Keep it as is, ignore beauty :). Always an option but maybe we can do better.
• Rename the patch-parser/src/patch/ folder to patch-parser/src/ast/ -- but abstract syntax tree is a bit much to claim for the data structures in here, currently anyway, since it doesn't pre-parse everything from the start. Maybe that should change, though.
• Use another name than ast for the above.
• Move patch-parser/src/patch/* to patch-parser/src/ -- but I don't like how it intermingles data abstraction and utilities.
• Re-export: but that's just making a virtual claim to the public (they still end up in the nested folder if they follow to source code with LSP), and in the public interface still intermingles data abstraction and utilities. I think re-exports are primarily good as a help when having to restructure something internally but keeping the public API unchanged. Not from the start to try to paper over a mess.
• Move patch-parser/src/patch/.rs to a new folder patch-parser/src/patch/utils/, then move patch-parser/src/patch/ to patch-parser/src/ -- or multiple folders not just one utils; but perhaps this is a sign to make new crates out of those.
• Take the above step to conclusion and also offer those utils or util groups properly, i.e. by moving them into their own crate(s).

I think I favour one of the last 2 cases. (If we sit together over it we can also do some of the work and have a better understanding, or I can go a bit closer over it myself--my main question is, do I find it worthy to publish the bumpalo approach things in a new crate!))

The things that are good to take away (learn from) in the end from this will be:

• Is making new crates the right thing pretty generally. This depends on:
  • how well do workspaces help?
  • are there tools to help move out files into their own crate? Because it's a little bit work intensive.
  • how do we avoid spamming crates.io too much? (Could use crate name prefixes like sp- or even split-patch-)

Well that's the main one.