Inconsistent naming of configuration files

[agarny]

We currently have the following configuration files:

cmake/cmake_command_check_code_formatting.in.cmake
cmake/cmake_uninstall.in.cmake
cmake/finalise_python_package.in.cmake
cmake/utils/compress.in.h
docs/conf.py.in                                    // docs/conf.in.py
docs/doxy.config.in                                // docs/Doxyfile.in?
docs/doxy.website.config.in                        // docs/Doxyfile.in.website?
src/bindings/python/setup.in.py                    // src/bindings/python/setup.pre_gen.in.py?
src/configure/libcellmlconfig_p.in.h
src/configure/mathmldtd.in.cpp
src/configure/mathmldtd.in.h
src/configure/versionconfig.h.in                   // src/configure/versionconfig.in.h
tests/api_headers/api_header_test.in.cmake
tests/api_headers/api_header_test.in.cpp
tests/bindings/python/test_resources.in.py
tests/test_resources.in.h

[nickerso]

I'd be inclined to go the other way and have all *.in.* files to standardise on the traditional *.in - makes it nice and clear which config files are templates to be customised at build time.

[agarny]

I believe it was @hsorby who wanted *.in.*. Originally, I was also in favour of *.in, but when it comes to opening a file by double clicking it, it's better to have *.in.* (for syntax highlighting). This being all said, I am really after consistency here. :)

[hsorby]

I am still in favour of *.in.* and would change those that are not consistent with that to be.

[nickerso]

Consistency would be good, I'm not totally against *.in.* being the basis for that consistency.

[agarny]

FWIW, libOpenCOR uses *.in. (I initially went with *.in.*, bu it quickly felt "wrong" to me, not to mention that I have yet to see any project that uses *.in.*.)