Add FQDN endpoint identifyer

[philsbln]

Add an option to distinguish FQDNs from unqualified HostNames to address concerns from #1460

[mwelzl]

"ABSTAIN":

I see, this implements a comment you added to a previous PR.

Is this an improvement or not? I'm not sure - on the one hand, it makes the API bigger, but on the other, it makes the dangers of not using an FQDN somewhat more explicit. That's a bit like our decision to have an "InitiateWithSend" call as opposed to adding a "data" parameter to "Initiate".

There's a design trade-off here, and I'm undecided about what is better.

Also, I'm not sure it's a good idea to make such a change that late in the process.

[tfpauly]

Suggested change

	- FQDN (string containing a Fully Qualified Domain Name):
	~~~
	RemoteSpecifier.FQDN("example.com")
	~~~
	- HostName (string that gets qualified while resolving, e.g., using DNS search domains):
	- HostName (a string, which SHOULD be a Fully Qualified Domain Name):

[tfpauly]

Suggested change

	Applications creating Endpoint objects using `WithHostName` should consider using fully-qualified
	domain names (FQDNs) instead. Not providing an FQDN will result in the Transport Services Implementation
	Applications creating Endpoint objects using `WithHostName` SHOULD provide fully-qualified
	domain names (FQDNs). Not providing an FQDN will result in the Transport Services Implementation

[mwelzl]

Can we close this?

I think the consensus was that it would only be ok to do with the changes suggested by @tfpauly , but then this does not really add any extra functionality since names are already specified to be FQDN's with a SHOULD.

[tfpauly]

I think this is fine to close

[philsbln]

With the changes discussed, it does not really add any value but adds changes to the next review phase