removing the support for older packet-ccm cloud provider

[displague]

Consider removing the support for older packet-ccm cloud provider entirely, only supporting cloud-provider-equinix-metal (equinixmetal prefix). The method of introspection we used to figure out which cloud provider folks had installed:

• Doesn't work with the newer controller runtime code
• Is a bit of a hack where we had to swallow client errors to get it to work
• Would require a lot of weird refactoring and eating of wrapped errors to work now
• Doesn't seem needed at this point as who is even using the older packet-ccm at this point?
• Is not how upstream docker handles it (they just set providerid prefix to docker:////) or another provider like azure handles it (they just straight up go with the UUID and no prefix, it seems).

Originally posted by @cprivitere in https://github.com/kubernetes-sigs/cluster-api-provider-packet/issues/674#issuecomment-1836857503

[displague]

Covered in:

• 06514d8fe1ab34da9109ef3037c1c2ac517373a3
• ad7e5b091fd554feb12514ae375408200cb92a75
• 7d010033837ee37a4b3803d65c0ebeb6a5bf7f3c

[displague]

Removal of the packet-ccm means that we can assert there is only one supported CCM type and we will no longer need to detect which may be running.

The commits above indicated through semantic commit tags that this is a breaking change, as such it will be called out in the release notes.

[displague]

Closed by #691