dev: Add template for VSCode settings and devcontainers

[chme]

This PR aims at making the set up of a new development environment for OwnTone a bit easier for newcomers by offering near automatic set up for VSCode with the help of devcontainers.

Setting up a development environment for OwnTone is not a trivial task. To get everything working from the C compiler chain, the dependencies, the web interface and building the documentation, requires a lot of knowledge which tools have to be installed etc. There exists already a lot of documentation (from the docs to the container files or the github yaml files), but you have to dig a bit through the different sources to get everything working.

With this PR, to set up a fully working environment it should be enough to:

• copy .dev/vscode to .vscode
• copy .dev/devcontainer to .devcontainer
• open the project in VSCode
• Choose the option to open the workspace in the devcontainer (VSCode popup dialog)

VSCode will then use the config in .devcontainer to build a container image that contains all the necessary tooling and then opening the workspace in this container. The build is only necessary once, it takes quite a while to finish, but subsequent opening of the workspace are much faster.

In addition to making the onboarding for new contributors easier, devcontainer also make it easier to test different scenarios, e. g. with different userspace (ubuntu, fedora, ...) or different dependency versions (e. g. building libevent from git). For example, I used it to test the later by copying the "ubuntu" subfolder and modifying the Dockerfile to build libevent from git.

The first commit, requires a closer look. It adds a command line argument to specify where the sqlite extension for OwnTone can be found. This allows to point to the locally build (and not yet installed) extension.

The second commit adds the config files for VSCode / devcontainers. Because I like a bit of terminal bling, there are some non essential tools installed like starship and atuin.

I also added a first version of a .clang-format file to make formatting easier (VSCode has issues with mixed tabs/spaces), but this needs a bit of work to tweak it for minimal changes across the C code base.

Let me know, if you think, this is helpful. If this is something that you consider merging, I will add some documentation to the docs.

[ejurgensen]

This would be a great addition. Would like to get started with VSCode myself to try the AI stuff.

I'm always a bit conflicted about how easy it should be to contribute to OwnTone. I don't really want "hit-and-run" contributions. Reviewing "foreign" PRs is also a mixed bag. So for my own sake I consider a modest barrier a good thing. For instance, the tabs/spaces mixture is in principle silly, but I've noticed that if I get a PR from someone who got them right, it's a subttle indication that the submitter has been careful to study existing code.

[hacketiwack]

Would like to get started with VSCode myself to try the AI stuff.

Visual Studio Code is my default editor since years, love it. Regarding AI, well, have a try, but don't expect much.

[chme]

I added some documentation to a new "development" page in the docs. This should give some pointers on how to use the dev containers. Let me know if something is unclear and needs more information.

Regarding AI, well, have a try, but don't expect much.

Yes, I agree, the AI stuff can be frustrating as often as it can be helpful ... I guess, we still have a fair amount of time until the AI takes over :-)

So for my own sake I consider a modest barrier a good thing. For instance, the tabs/spaces mixture is in principle silly, but I've noticed that if I get a PR from someone who got them right, it's a subttle indication that the submitter has been careful to study existing code.

I can feel your pain :-)
Though, something annoying as code formatting, might also put off some skilled contributors. From my experience, if a project has a good contributing page and some docs on how to get started, I am more willing to spend some of my spare time.

I think, the clang-format config is already pretty good. There are some formatting inconsistencies and tweaking it for one file ends up messing up others ...
If you want to take a look at it, here is the entire code base formatted with clang-format:
chme@bd26f06