Add NameServers to Fn::GetAtt for AWS::ServiceDiscovery::PublicDnsNamespace

### Name of the resource

Other

### Resource name

AWS::ServiceDiscovery::PublicDnsNamespace

### Description

Currently, in order to retrieve NameServers for AWS::ServiceDiscovery::PublicDnsNamespace, CustomResource/Lambda is required, yet, it is very logical Attribute to retrieve when using AWS::ServiceDiscovery::PublicDnsNamespace.

Consider a scenario, where you create AWS::ServiceDiscovery::PublicDnsNamespace as foo.bar.com, where bar.com is your HostedZone, and foo is NameSpace -> Subdomain mapping.

This will create new HostedZoneId in your Route53, managed by CloudMap, yet, it won't resolve publicly (Mind that it's Public Namespace with intention to be resolved) unless you add given new HostedZoneId NameServers to Apex HostedZone (bar.com) as NS entry.

### Other Details

Usage example currently:

```yaml
Resources:
CloudMapNameSpace:
Type: "AWS::ServiceDiscovery::PublicDnsNamespace"
Properties:
Name: !Sub "${AWS::Region}.dashboard.${ApexDomainName}"

CloudMapNamespaceOutput:
Type: Custom::NameServersOfCloudMapNamespace
Properties:
ServiceToken: !Ref CloudMapRegisterLambdaArn # Lambda returning Attribute NameServers
CloudMapNamespaceId: !Ref CloudMapNameSpace

CloudMapHostedZoneParentRecord:
Type: AWS::Route53::RecordSet
Properties:
HostedZoneId: !Ref DomainZoneId
Name: !GetAtt CloudMapNamespaceOutput.Name
ResourceRecords: !GetAtt CloudMapNamespaceOutput.NameServers
Type: NS
TTL: 60
```

Start with the AWS::ServiceDiscovery::PublicDnsNamespace resource and its current Fn::GetAtt attributes, then compare the requested NameServers value with the YAML usage example. Confirm how the existing Custom::NameServersOfCloudMapNamespace Lambda obtains the value and what CloudFormation coverage change would expose it; done means NameServers can replace that custom-resource output.

Written by the indexing model from the issue text.