Cookiecutter-django: Expand docs to comment on project structure vs 2 scoops recommendation

[yunti]

Although the docs make a brief comment that the cookie cutter-django may be different to that recommended by the 2 scoops book - it would be useful to have a comment in the docs explaining the project structure and how best to use it.
In 2 scoops we broadly have:

repo_root/
     readme
    django_project_root/
          manage.py
          django app1/
          django app2/
          static/
          templates_site_wide/
          config/

Whereas in djangocookiecutter it appears more flattened (after the output from cookie cutter):

django_project_root(also_repo_root)/
     readme
     manage.py
     config/
     django_app1/
     django_app2/
     main_django_app/
            tempates_site-wide/
            static/
            users/

One of the main difference seems to be putting (site-wide) templates down a level vs the individual django apps and also getting rid off the additional top level for the repo. Would be interesting to hear comments on the benefits of the choice of approach and see if we summarise briefly in the docs as it's a little bit of a jarring diff coming from reading the book.

[pydanny]

@yunti, I think your understanding doesn't mine. The current architecture of Cookiecutter, which was suggested and implemented by @theskumar is:

repo_root/
    compose/
    config/
    docs/
    project_root/
        django_app1/ 
        django_app2/
        static
        templates/
        users/

This forces us to namespace app packages thus in imports project_name.users. Some more history:

1. @theskumar argued for it, and I was hesitant. I trust his judgement, so I thought, why not try it?
2. Then I decided I didn't like it. In monolithic projects it can be annoying to namespace packages during imports. It wasn't a terrible issue, so I mostly let it go.
3. Recently I realized @theskumar was absolutely correct. The namespace is a super-powerful feature. At some point I'll document the use cases (which @theskumar tried to educate me on, but I was thick-headed).

Having used both and also now understanding @theskumar, I'm going to try and document the power of his approach.