Proposal: Fix inconsistent DNS driver API implementations

## Summary

While comparing the LuaDNS driver to other DNS drivers, I noticed that there are a number of subtly incompatible implementations sharing an otherwise common API which limit portability between providers.

For example, some drivers use empty strings to represent apex/naked records (e.g. example.com.), while others use `None`. Both categories of drivers employ explicit unit testing to confirm their preferred `Record.name` value.

Similarly, some drivers want `Record.name` as a rooted FQDN (e.g. `"host.example.com."`), others as an unrooted FQDN (e.g. `"host.example.com"`), and still others as a bare host name (e.g. `"host"`).

## Proposal

Assuming that the **libcloud** DNS class/driver APIs are intended to provide a consistent interface for users and drivers should provide logic within themselves to adapt the common objects and interfaces for their respective services, I propose the following:

1. Add common logic to the `Record` class to standardize apex/naked record names on the empty string (or `None`).
2. Add common logic to the `Record` class to enforce that `.name` represents the host name, without the domain suffix. This would likely involve adding new `.fqdn` and `.hostname` properties to expose rooted and unrooted FQDN strings, respectively.
- For the sake of compatibility with existing uses, `__init__()` would accept a rooted/unrooted FQDN, a bare host name, or `None`.
3. ~~Refactor `Record.update()` to leverage common code to enforce the items above, while being kind to existing users.~~
4. Expand DNS driver unit tests to validate data sent *to* the provider. Presently, it appears that testing primarily validates the formatting of (canned) responses received *from* a provider.

Inizia leggendo la classe DNS Record e il suo metodo update(), quindi confronta i test unitari dei driver DNS esistenti menzionati nella proposta. Traccia il modo in cui i driver formattano Record.name per le richieste e le risposte dei provider. Per considerare il lavoro completato servono un’API comune per i nomi concordata, un comportamento di compatibilità e test che coprano i dati inviati ai provider, ma la proposta non identifica file specifici né definisce il design.

Scritto dal modello di indicizzazione a partire dal testo della issue.