feat: add use_internal_ca_certs option for local_auth_endpoint

[banschikovde]

Issue

Resolves #1299

---

Problem

When enabling the local_auth_endpoint for a cluster, users could not opt into using the internally generated CA certificate.
Attempting to retrieve the CA certificate through a data.rancher2_cluster data source led to a dependency cycle, and only an external CA could be configured directly.

---

Solution

• Added a use_internal_ca_certs boolean flag inside the local_auth_endpoint block, mutually exclusive with ca_certs.
• Introduced logic to fetch the cluster’s internal CA and populate it when use_internal_ca_certs is true during create, update, and read operations.
• Updated diff handling and helper functions so the flag is tracked in state and diffed correctly.
• Expanded resource documentation and unit tests to cover the new behavior.

---

Testing

Engineering Testing

• Ran make build to compile the provider.
• Verified go test ./rancher2 -run TestExpandClusterV2LocalAuthEndpoint -count=1 -v after enabling the new flag.
• Executed make test to confirm all unit tests pass with the new logic.

Automated Testing

• Added unit tests for TestExpandClusterV2LocalAuthEndpoint and updated existing tests to assert state preservation of use_internal_ca_certs.
• Existing unit test suite validates mutual exclusivity between ca_certs and use_internal_ca_certs.

---

QA Testing Considerations

• Confirm that enabling use_internal_ca_certs on a cluster with local_auth_endpoint correctly pulls internal CA data without requiring explicit ca_certs.
• Validate upgrade scenarios: clusters configured with ca_certs should behave unchanged, while toggling use_internal_ca_certs should swap to internal CA seamlessly.

---

Regressions Considerations

• Potential regression in cluster diffing logic around local_auth_endpoint fields; verify that state refresh and plan outputs remain stable.
• Low probability, but focus on any workflows combining use_internal_ca_certs with other cluster CA options.