fix(p/BUNNYDNS): return the zone's nameservers and ignore apex NS records

[jfexyz]

Fixes #4890.

The problem

Since v5, GetNameservers for BUNNY_DNS returns an empty list (changed in #4607). That has two visible effects:

• A registrar on the same domain is skipped with No nameservers declared for domain, which is what BUNNY_DNS: Not returning nameservers for registrar #4890 reports.
• Working around that with explicit NAMESERVER("kiki.bunny.net.") / NAMESERVER("coco.bunny.net.") gets the registrar check back, but DNSControl then wants those as apex NS records in the zone. Bunny DNS does not list apex NS records through its API and rejects creating them, so every preview shows two CREATE corrections per domain, and push fails them with NS records are not supported on the root of the domain.

The change

• GetNameservers returns the zone's Nameserver1 / Nameserver2 again, as it did in v4.
• Apex NS records are removed from the desired state before diffing, since Bunny DNS manages them itself. This is what keeps the nameservers from GetNameservers (or from NAMESERVER()) from turning into corrections that can never be applied.
• If a removed record names a nameserver the zone is not served from, a warning is printed instead of dropping it silently. DNSIMPLE, EXOSCALE and GANDI_V5 handle their managed apex NS records the same way.
• The special case that zeroed the TTL of apex NS records is gone, as those records no longer reach the diff.
• A caveat in the provider documentation describes the behavior.

This differs from the v4 implementation, which injected the zone's nameservers into the existing records as "implicit" records. Filtering the desired state instead needs no placeholder records and no guards against changing or deleting them, and it also quiets the case from #3570, where an apex NS record that Bunny DNS cannot hold produced a failing correction on every push.

BUNNY_DNS stays excluded from the NS only APEX integration test.

Testing

• go test ./providers/bunnydns, including a new unit test for the filter.
• bin/generate-all.sh leaves no other changes (golangci-lint and staticcheck are not installed here, so those two steps were skipped).
• dnscontrol preview with a build of this branch against 12 real Bunny DNS zones using the DNSOVERHTTPS registrar:
  • with explicit NAMESERVER() for both Bunny nameservers: 0 corrections (24 on v5.3.0);
  • without any NAMESERVER(): 0 corrections, and the registrar check runs instead of being skipped;
  • with a NAMESERVER() that is not one of the zone's: the new warning, no DNS provider correction, and the registrar reports the differing set.

Not tested: push, creating a zone that does not exist yet, zones with custom nameservers, and the integration test suite, as I have no test zone to run it against.

@ppmathis, since #4607 removed this on purpose, I would appreciate your view on whether this approach works for the cases you had in mind. I'm hoping to find a way to use the Bunny provider and a registrar provider; the way it currently works creates too much noise and makes it difficult to recognize actual warnings.

[dlong500]

Is there anything holding up this PR? It would be great to get this fix rolled out.