Making the "new repo" requests go faster

[Ed Tanous]

An issue I've seen in the past with adding new repositories, is there:
1. Isn't a clear place to push code reviews for something "new".
2. The project quality/CI/formatting rules aren't really enforced
until after you request a repo, then push code to it.
3. Setting up a new daemon with CI/build is non-trivial, and has sharp edges.
4. "state of the art" build constantly changes (make -> autotools ->
cmake -> meson, clang-format, clang-tidy, shellcheck, cppcheck,
service file location, ect).

In an effort to fix these issues and more, I'd like to propose
creating a new repository for a "new daemon" template.  The hope would
be that we can centralize a single set of "current state of the art"
guidelines in such a way that they're usable more than just checking
them into documentation.  Initially, template repo would contain:

1. A meson file, that compiles a "hello world" dbus application that
requests a name.
2. All the relevant .clang-tidy, .clang-format, and cppcheck files
required to ensure that CI is testing as much as we can.
3. Unit tests
4. Pre-integrated repo CI.

The end goal of this would be that when new code is created, whomever
was looking for a new repository could push a gerrit review to this
"template repo" and the CI could ensure that it met the automated
quality requirements long before any maintainer actually reviewed it.
This would likely reduce the time it takes to propose "I want to add a
new repo" and make a procedure for doing it a lot more concrete than
sending an email to the mailing list.

As part of this, I'd also want to deprecate and remove the .clang-tidy
and .clang-format that are present in the docs repo, and supersede
them with the files in the new repo, such that any changes to the CI
infrastructure could be proposed on the template repo first.

FWIW, I take no credit for the above idea, I 100% stole it from James
Feist, who thought through the broad strokes of this a while back when
we were talking about how to move new initiatives along faster without
burdening maintainers.

I'd love feedback.  Do others think this worth doing?

-Ed