In a new module 'cubicweb.pyramid.config' we define a "pyramid" instance
configuration type. The noticeable feature of this configuration is that it
manages a 'development.ini' file that gets installed in application home
(along with `.conf` file). This file is templated and includes generated
values for secrets of session and authtk tokens.

This means that we can just call:

    pserve etc/cubicweb.d/<appname>/development.ini

or

    gunicorn --paste etc/cubicweb.d/<appname>/development.ini -b :8080

just after instance creation to get a pyramid instance running without having
to hack around a 'pyramid.ini' file.

This patch drops 'development.ini' from skeleton and moves it in
cubicweb/pyramid so that it gets installed at instance creation which is more
appropriate than in cube creation.

The new configuration class sets "cubicweb.bwcompat" setting to false so it is
not intended to replace the "all-in-one" configuration type (which would
require a bit more work). This configuration is close to the the 'repository'
configuration type with just a couple of options from WebConfiguration that
are needed for Pyramid (anonymous user/password plus some miscellaneous
options that I'm not so sure are really needed). Note, in particular, that we
do not pull CORS settings to be injected as a WSGI middleware like in
wsgi_application_from_cwconfig() since I believe this should be left as an
end-user responsibility and since this can be defined in a standard way in
paste configuration. This configuration inherits from ServerConfiguration but
registers the same appobjects as WebConfiguration.

In cubicweb.web.request._CubicWebRequestBase, we guard against access to
"uiprops" and "datadir_url" of the config because this new "pyramid" config
does not have these (this does not make sense without bwcompat mode). At some
point, we should either avoid using `cw_request`'s pyramid request attribute
or make cubicweb's web request really independant of existing implementation
and drop these assumptions.