solidlsp: recognize Arduino .ino files as C++

[hampsterx]

What

.ino (Arduino sketch) files are C++, but they were absent from the CPP and CPP_CCLS source-file matchers in Language.get_source_fn_matcher(). So Serena routed them to no language server and rejected every symbol operation with:

Cannot extract symbols from file ....ino. Active languages: [...]

even with cpp configured as a project language. This adds .ino to both matchers.

Why the matcher alone isn't the whole story (and that's fine)

clangd builds its compile command from the filename, and the clang driver doesn't recognise .ino, so on its own clangd reports fe_expected_compiler_job ("Unable to handle compilation, expected exactly one compiler job") and returns no AST. The project just needs to declare the language, the same as any non-standard C++ extension. A .clangd in the source tree does it:

If:
  PathMatch: .*\.ino
CompileFlags:
  Add: [-xc++]

With that present, clangd returns the full document-symbol tree. Verified against a real 1872-line ESP32 sketch: hard-rejected by the matcher before (0 symbols), 204 symbols after. Without this matcher change no project config can help, because the file never reaches clangd.

Changes

• .ino added to the CPP (clangd) and CPP_CCLS (ccls) matchers, with a comment pointing at the .clangd / -xc++ requirement.
• Server-independent unit test asserting .ino (any case) matches for both languages, ordinary .cpp still matches, and unrelated files don't.

Test plan

• test_source_fn_matcher_includes_ino assertions verified (parametrized over CPP and CPP_CCLS): .ino / .INO / path-qualified .ino match, .cpp still matches, .md is rejected.
• End-to-end with clangd 22.1.0 over raw LSP: didOpen (languageId cpp) + documentSymbol on a real .ino returns 204 symbols when a .clangd supplies -xc++, and reproduces fe_expected_compiler_job without it.
• Full pytest -m cpp suite not run in this environment; the new test is independent of the language-server fixtures.