Doc build fix etc. etc.

[KennethNielsen]

This PR contains a slew of documentation build fixes, to make sure that the documentation builds cleanly. They contain:

An unrelated fix to the setting at ReadTheDocs to make sure that a new push triggers a documentation build. I also updated the build documentation python version from 2 to 3, which caused quite a bit of the need of the changes below. This once again comes to mind: https://media.tenor.com/Wh_Y3Uj_QHYAAAAd/simpsons-bugs.gif

1) In order to accommodate driver docs, both that are only autogenerated and those which have additional prose docs, I long ago made a script to update the necessary documentation stub documentation for the auto-generated documentation. @Ejler remember to run this script once in a while and particularly when drivers are added, removed or renamed. It is located at /doc/source/update-driver-only-autogen-stubs.py. In any case. all the changes in doc/source/drivers-autogen-only can be ignored in review as they are just auto generated stubs.

2) I made a few fixes to driver source code to make the documentation build cleanly. One was slightly amusing/puzzling. sensirion_sps30.py imports logger and uses it only once to call logger.warning. Almost certainly the intent was to import logging instead and call warning on that, so I changed it to that. But that then begs the question of how this even worked to begin with. My best bet is that the program that used this driver was in fact called logger.py and that it was that which was imported (the primary programs folder is always brought into path) and that the branch which called warning on it was never reached, thus hiding the obscure bug. @robertjensen git blame says the module is yours, so have a look to make sure I didn't mess it up.

3) I update the documentation conf.py to Python 3 and made a few module import hacks at the bottom. This trick occurred to me while I was making these changes and I thinks it is much preferable to how we have handled this problem before. In essence, we sometimes have the problem that certain package imports, or use at the module level, requires HW, which obviously isn't present on read the docs. In the past I have often handled this like this:

    ```python
    import sys
    if "sphinx" not in sys.modules:
        import hardware_dependent_module
    ```

however, I dislike this as it clutters up source with documentation build fixes. The IMO much betters solution is what I did now. Remembering that the docs conf.py is run before any modules are imported, and that once imported (the modules exists in sys.modules) it will not be imported again, the obvious (in hindsight) solution was to simply inject a fake version of the offending module into sys.modules. Have a look and let me know what you think. I did not go through all the drivers to look for the old abomination on this pass however, maybe sometime in the future.

4) I update the requirements-doc.txt to reflect the real dependencies required for building the docs.

5) I added a .readthedocs.yaml configuration file, which means that now certain of the settings for the documentation builds, can simply be done there, instead of through ReadTheDocs.

I hope you like it

[robertjensen]

Does this also fix PR49?

[KennethNielsen]

@robertjensen no, but that one is trivial and should just be merged.