Chef 2913 - Trace All Changes to Attributes

So, this is a big PR, and if/when it gets accepted, I expect there to be several rounds of rework.  Just setting expectations. :-)  It may not be ready for prime time, but it certainly needs more eyeballs on it at this point.

I'll be presenting about this feature at Chef Conf - "Bulletproofing your Attributes"

This feature allows you to trace each time an attribute changes, throughout the entire node building, compilation, and convergence process.  Unlike debug_value, which shows only the final state of the attribute at each precedence, attribute tracing actually reveals when attributes are overwritten, and provides extensive details on what did the overwriting (eg, the name of the role, or the cookbook attribute file with line number).

The feature is disabled by default, and is controlled by a Chef::Config setting.  You may trace none, all, or only attributes exactly matching a given path.  Attribute changes are emitted as debug-level log messages, and are also accessible programatically.

The implementation works by adding a trace log attribute to Chef::Node::Attribute, then modifying AttrArray and VividMash to notify the trace log whenever a mutator is used.  Currently, []= is traced for both, and << is traced for AttrArray; all other mutators are not currently traced.

A fairly extensive rspec test suite is included.  It is somewhat slow, running several client convergences against a chef-zero.  Could be sped up by combining runs, probably.

There are a couple of things I'd like to call out as being problematic, and I'm sure the reviewers will have more....

1. Without more invasive changes, there is no easy way to determine the "path" of an attribute from a mutator call.  Currently, an inefficient brute force search is used.  That may be enough; attribute tracing is intended to be a diagnostic tool, and maybe having bad performance while it is enabled is acceptable.

2.  Identifying the source of the change is handled through callstack introspection and a series of heuristics.  That will be brittle over time, being somewhat sensitive to refactoring.

3.  In the course of adding hooks to AttrArray, I found that array attributes are handled very inconsistenly compared to VividMash; for example, VividMashes convert all of their values to VividMashes or AttrArrays, while AttrArrays do not convert their elements - so default[:foo] = ['thing1', {'thing2' => 'value'}] will contain a plain Hash, not a Mash or VividMash.  I went ahead and "fixed" that issue; I'd be happy to split that out as a separate ticket, if desired.