Automatically generate LSP configuration files

[tdaron]

cf #49

[obiwac]

Some context: This was originally issue #47 resolved in #49 which was in Bob v0.1. This got removed when moving over to v0.2 in favour of just using intercept-build from LLVM (plz merge llvm/llvm-project#123252 😠), but it still would be nicer to just have this integrated in Bob.

Now, this will be slightly easier than it was back then because we aren't trying to build Rust projects ourselves anymore, but we will still need to generate a compile_commands.json database for C/C++ code.

Other things to keep in mind:

• Do we want to be able to generate a compile_commands.json which includes all dependencies? So that e.g. we can build this database once at the top level aqua directory and then have everything work, instead of having to build this once per subdirectory. I don't really know how we'd implement such a solution though.
• Do we want to generate/update the database automatically on build, or do we have a special separate command like v0.1 had (bob lsp)? Also, do we want to automatically update compile_commands.json if found next to our build.fl?
• We should have a warning about not having compile_commands.json (and .bob too for that matter - see Make sure output path is in .gitignore #125) in .gitignore, if one exists.

[obiwac]

Okay more thinking aloud here:

• After thinking for more than 2 seconds, I really don't think it's a good idea to have a single compile_commands.json for the parent project of a bunch of dependencies. Because it means that if you do a command line option or header path change or something in a dependency, it has to somehow know to update that in all it's parents. I don't see how that would be practical. So I think I'm going with a compile_commands.json per dependency.
• Now, when jumping to definition, I don't wanna show the header in the prefix, because that would be annoying. Instead, I would like to show the header in the dependency project it actually came from. This is... not gonna be easy. Especially since it means each dependency has to somehow communicate to its parent all the resource -> prefix path mappings. And what about generated headers? I guess in this situation it's probably fine to just jump to where it is in the prefix...