Support ni-tls-config Directory Scheme and Add TLS Configuration Templates

[texasaggie97]

What does this Pull Request accomplish?

This PR enables mutual TLS support in grpc-device through integration with NI managed certificate configuration via ni-tls-config. The work includes:

1. TLS loader enhancements
   Refactors TlsConfigLoader to use ni-tls-config contents APIs instead of direct file-path parsing, enabling directory:// support for trusted certificate bundles.

2. TLS configuration templates with explicit role naming
   Introduces role-explicit template source names so usage is clear at the source level:

   • ni-grpc-device.server.conf.yml
   • ni-grpc-device.server.caps.yml
   • ni-grpc-device.client.defaults.yml
   • ni-grpc-device.client.caps.yml

3. Canonical runtime filename mapping during staging
   Preserves canonical ni-tls-config runtime filenames during staging so runtime behavior stays compatible:

   • server source templates stage/copy to ni-grpc-device.conf.yml and ni-grpc-device.caps.yml
   • client source templates stage to ni-grpc-device.defaults.yml and ni-grpc-device.caps.yml

4. Client artifact staging cleanup
   Updates client staging to use client.d as the staging folder (instead of config) for ni-tls client artifacts, improving clarity and resolving reviewer feedback around naming intent.

5. Example configuration and feature gating
   Adds server_nitlsconfig.json to demonstrate secure configuration with:

   • "security": "ni-tls-config"
   • "feature_toggles": { "ni-tls-config": true }

6. CI/artifact updates
   Updates workflow artifact packaging and staging logic so the new template naming model and canonical output mapping are included consistently.

7. URI scheme normalization
   Standardizes URI schemes to lowercase file:// and directory:// for consistency.

Why should this Pull Request be merged?

This change improves TLS security support while reducing naming ambiguity for maintainers. It keeps runtime compatibility by preserving canonical ni-tls-config filenames, but makes source ownership and intent explicit with server/client template naming. It also aligns artifact layout with clearer client.d staging semantics and addresses reviewer concern about confusing export naming behavior.

What testing has been done?

• TLS loader builds and unit tests pass with the contents API integration.
• End-to-end mutual TLS handshake validated on Windows host and NI Linux RT target.
• Server correctly loads trusted certificates via directory://.
• Client and server certificate exchange flow validated using automation.
• Workflow and staging logic validated for template inclusion and canonical filename outputs.
• URI normalization validated with lowercase file:// and directory:// schemes.
• YAML template syntax validated.

[maxxboehme]

With these new client and server configuration files. I think there should be a readme update clearing up their uses.