Frictionless Nimble directory structures
Currently Nimble is quite picky about the valid project structures, see https://github.com/nim-lang/nimble#project-structure. This is often annoying for Nimble users and even if it weren't, it's something people have to learn and remember and is hardly justified. "Namespacing" is often used as the justification but that is not necessarily Nimble's job. If package A and package B both offer ``utils.nim`` in their top level directories, it could still be possible to disambiguate manually like ``import A / utils``. And soon enough the package's users will demand sane names anyway.

A slightly different, but more pressing problem is that Nimble only copies the .nim files from ``srcDir`` over to the "installation" destination. In other words, the installation environment differs from the devel environment. That is asking for trouble and even if it works, it means the users of a package do not see the example programs or the documentation because it is not "installed" at all!

Nimble should simply ``git clone`` a package followed by a ``git checkout`` to select the required version/commit. This would also simplify the creation of eventual pull requests that the package's user might want to do. But even if Nimble continues to download/copy the package's files without the hidden ``.git`` directory, it should not touch the directory structure and it should not "install" only a selected set of files.

So what previously was ``$nimbleDir/p-1.0.0/p.nim`` becomes ``$nimbleDir/p-1.0.0/p/src/p.nim``, for example. For backwards compat the Nim *compiler* can then resolve an import like ``import p`` to ``import p/src/p``.

# Advantages

- ``cd $nimbleDir/foo && nimble docs`` or any other build target works out of the box without any special logic in the project.nimble file.
- Nimble's source code becomes simpler, fewer project structure rules to enforce. 
- Nimble becomes easier to use.
- It seems to be completely backwards compatible.

# Disadvantages

The Nim compiler must do a bit more work to resolve imports. However, already it needs to be aware of the $nimbleDir, versions and "nimble develop" redirections. It is not a big deal to add slightly more logic on top of this mess if Nimble becomes easier to use and understand as a result.


# Open Questions

How to handle git repos that contain multiple nimble packages? 