[ concern/question ] Nimble complaining about incorrect folder structure, warning about becoming an error
I want to raise a concern about these warnings.
They have been plaguing all my projects since the last update on stable:
```nim
  Warning: Package 'nid3' has an incorrect structure. It should contain a single directory hierarchy for source files, named 'nid3pkg', but file 'build.nim' is in a directory named 'src' instead. This will be an error in the future.
      Hint: If 'src' contains source files for building 'nid3', rename it to 'nid3pkg'. Otherwise, prevent its installation by adding `skipDirs = @["src"]` to the .nimble file.
```

My project's structure (all of them are built the same):
```md
RootRepository
|- src/
|   |- libname.nim
|   |_ libname/
|        |- sub1.nim
|        |- sub2.nim
|
|- bin/
|    |_ .gitignore
|
|- libname.nimble
|- config.nims
```
This allows for:
```nim
# nimble install libname
import libname           # Access to the normal root module
import libname/sub1      # Access to the submodule1 specifically
import libname/sub2      # Access to the submodule1 specifically
import pkg/libname/sub1  # Explicit specification for the file being from a package, and not a current folder file/folder
```

What the warning of a future error is enforcing:
```nim
import libname              # Access to the normal root module
import libnamepkg/sub1      # Different prefix name for the submodule
import libnamepkg/sub2      # Different prefix name for the submodule
import pkg/libnamepkg/sub1  # Explicit specification for the file being from a package, and not a current folder file/folder
```

Have a few questions:
1. Is there a way to silence these warnings?
2. Why is there an enforced project structure now?
3. Why is there even a need for removing the normal `src/pkg/* + src/pkg.nim` structure that has always worked?
4. Why am I forced to call all my submodules with `import mylibpkg/sub` or even `import pkg/mylibpkg/sub` if my project requires the explicitness, instead of just `import pkg/mylib/sub` like it makes sense to do?
5. How far away is this `future` that the `this will be an error in the future` message is pointing at?

I have asked on discord before, and I've been told to ignore them.
But I don't want to ignore a warning that is warning me about itself becoming an error in the future.
Sounds like a warning I should not ignore, if it's warning me of all my packages breaking completely in the future if I don't want to fit in the narrow box that this enforces.

Is there any chance of a reconsideration on the future error enforcement?
Is there a dialogue on this, or is it just gonna be enforced and required without making it optional in any way?

Hope I don't sound angry, I'm not. I'm just surprised that this warning even exists, so figured I should write an issue about it.
Thanks for such an awesome tool, I really believe in this manager.
Let me know what you think :writing_hand: