feat: Azure Provider HasInstance implementation

[Bryce-Soghigian]

What type of PR is this?

/kind bug
/kind regression

What this PR does / why we need it:

CA fails to scale up or cancel in progress schaledown when there are unschedulable pods. Stealing this description from the aws provider implementation.

I think the description of #5054 (comment) explains it well:
...original intent of determining the deleted nodes was incorrect, which led to the issues reported by other users. The nodes tainted with ToBeDeleted were misidentified as Deleted instead of Ready/Unready, which caused a miscalculation of the node being included as Upcoming. This caused problems described in #3949 and #4456.

Which issue(s) this PR fixes:

• [BUG] Cluster autoscaler bug requires Azure specific implementation to resolve Azure/AKS#4286
• CA fails to scale-up or cancel in-progress scale down when there are un-schedulable pods  #4456

Special notes for your reviewer:

This PR introduces the HasInstance method to the Azure provider for Cluster Autoscaler. The primary purpose of this method is to ascertain whether a given node has a corresponding instance in the Azure cloud provider. This implementation helps to prevent the undercount of existing VMs and addresses issues related to the taint-based overcount of deleted VMs.

• The HasInstance method ensures that if it is uncertain whether an instance exists, it returns an error instead of false, nil. This approach enforces a fallback to the taint-based determination method, providing a more reliable count of existing VMs.
• If the instance exists: return true, nil
• If the instance does not exist: return *, ErrNotImplemented (consider using a custom error for autoscaled nodes)
• For unimplemented cases: return *, ErrNotImplemented
• For any other errors: return *, error
• ErrNotImplemented is used for silent fallback, while any other errors will be logged for further investigation.

Does this PR introduce a user-facing change?

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[Bryce-Soghigian]

/test all

[tallaxes]

Overall LGTM, with minor feedback, and some comments re implication of using cache.
How was this tested? Can we add unit tests? E2E tests?

[tallaxes]

/lgtm