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.

首先阅读 DNS Record 类及其 update() 方法，然后对比提案中提到的现有 DNS 驱动单元测试。跟踪驱动如何为发送给提供商的请求和从提供商返回的响应格式化 Record.name。要完成此工作，需要一个达成共识的通用命名 API、兼容性行为，以及覆盖发送给提供商的数据的测试，但提案没有指出具体文件，也没有确定设计。

由索引模型根据 Issue 内容生成。