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.

Comienza leyendo la clase DNS Record y su método update(), y después compara las pruebas unitarias de los drivers DNS existentes mencionadas en la propuesta. Sigue cómo los drivers formatean Record.name para las solicitudes y respuestas de los proveedores. Para darlo por terminado se requiere una API común de nombres acordada, un comportamiento de compatibilidad y pruebas que cubran los datos enviados a los proveedores, pero la propuesta no identifica archivos específicos ni establece el diseño.

Escrito por el modelo de indexación a partir del texto del issue.