Support external validator registration via system property and merged settings

[esmasth]

Problem

1. extension.validators overrides instead of merging across settings levels

The extension.validators preference is resolved like all other preferences: the highest-priority settings level wins. This means a project-level yang.settings with only excludePath will silently override a user-level yang.settings that configures extension.validators, causing validators to not load.

Expected: Validators from all settings levels (constantSettings, user, workspace, project) should be merged, since they are additive by nature.

2. No way to inject validators without yang.settings

Editors and launchers that want to register validators (e.g., from a VS Code extension contribution API) currently have no mechanism to do so without writing to yang.settings files. A system property like -Dyang.extra.validators would allow launchers to pass validator class names directly.

3. No way to extend the server classpath at launch time

The launch scripts have a hardcoded CLASSPATH. External jars containing validator implementations cannot be added without modifying the scripts. An environment variable like YANG_EXTRA_CLASSPATH would allow launchers to append jars dynamically.

Proposal

1. Add getMergedExtensions() to ExtensionProvider that walks the MapBasedPreferenceValues delegate chain and collects values from all levels using a LinkedHashSet for deduplication. Use it for extension.validators in ResourceValidator.

2. Read -Dyang.extra.validators system property in the server launcher and populate PreferenceValuesProvider.constantSettings with the value.

3. Add YANG_EXTRA_CLASSPATH support to the generated launch scripts, appending its value to the classpath.

Related: TypeFox/yang-vscode#110