feat: add support for Salesforce Apex language (.cls, .trigger, .apex)

[pranav440]

Fixes #175

Description

Adds out-of-the-box support for Salesforce Apex (.cls, .trigger, .apex):

• Added **/*.cls, **/*.trigger, and **/*.apex to DEFAULT_INCLUDED_PATTERNS.
• Added DEFAULT_LANGUAGE_MAP in settings.py mapping .cls, .trigger, .apex to java (Apex shares Java-like syntax/grammar and tokens for semantic AST/chunking).
• Updated indexer.py to use DEFAULT_LANGUAGE_MAP during language resolution fallback.
• Added comprehensive unit tests in tests/test_settings.py verifying pattern inclusion and language map values.

Verification

All 72 unit tests in tests/test_settings.py pass cleanly.

[ashwingadhave]

I tried this branch on trailheadapps/apex-recipes (139 .cls and 3 .trigger files). Some notes.

The java grammar does help. With plain text splitting about 73% of chunks start on a declaration or a comment. With java it is about 84%, and chunks starting in the middle of a statement go from 27% to 16%. So I agree with the direction.

But the language stored in the index becomes java. detect_code_language already returns apex for .cls and .trigger, and the new map runs before it. After ccc index on this branch I see 883 apex chunks stored as java and none as apex. On main with the same include patterns added in settings.yml they are stored as apex.

Also .cls in the default include patterns was already declined in #199 because of the LaTeX and VB collision. .apex is fine, core does not know that extension at all so there is nothing to collide with.

One more thing. DEFAULT_LANGUAGE_MAP is a module constant, so it is not part of the memo key. language_overrides was moved to an argument in #299 for exactly that reason.

What worked for me is to keep the detected language and only change the grammar used for splitting:

SPLITTER_GRAMMAR_FALLBACK = {"apex": "java"}
...
language=SPLITTER_GRAMMAR_FALLBACK.get(language, language),

On main with the include patterns this gives the same 883 chunks as this PR but stored as apex. Test suite is unchanged. Then a line in the README for Salesforce projects showing the two include patterns, since that is the route georgeh0 preferred in #199.

I can send that as a separate PR, or you can pull it into this one. Up to you.