Attribute API 2

**NOTE:** This RFC is incomplete, the specification of the new feature is TBD.

This RFC describes a new attributes API to be added alongside the current one. The goals of this new API are:

* Separate desired and observed state.
* Structure the syntax in a way that "trainwreck" errors
  (`NoMethodError` for `[]` on `nil`) can be avoided.
* Structure the syntax in a way that attribute tracing can be
  implemented simply.
* Separate node-specific persistent storage from
  cookbook/role/environment attributes.
* Structure the syntax in a way that can be implemented efficiently.

This RFC is adapted from https://github.com/opscode/chef-rfc/pull/9 which is retracted.
It should probably be clear here that the proposal is to include a new storage 'thing' on the server that will be used for persistence which is not the node object.

For back-compat we'll support normal attributes in the existing node object, but should emit a deprecation warning on those -- people that have their mysql passwords stored as normal attributes (which they should **NOT** of course) will still continue to be able to do that.

The run_list and tags would presumably be moved over to the new storage location, which could conceivably be a breaking change (I don't immediately see how you keep the two storage locations in sync in order to mirror the normal attributes).

What happens to tools like 'knife node edit' where people expect be able to edit their run_list in their editor?

Since this storage location stores the run_list then it pretty much has to be indexed and be 'public' since people (and nodes) want to search on that and see it.

It would be nice to have another storage location which was similarly persistent and node-local that had default perms of r/w only for the individual node and for admins which was also **NOT** indexed.  If we're going to add a new storage location, I'd really like to add this feature since it'll solve the problem of "i want to write creds to this machine and not have an attacker on a different box have access to those creds *AND* I trust my Chef Server isn't broken into and can do AAA".  I think it would be easier to for users to deploy than Chef Vault and hits a reasonable security bar since most sites will just assume they're toast if their Chef Server is busted into.