Fix HABTM for all_parents and all_children.

Since all_parents and all_children get their information from a view
instead of a normal table, ActiveRecord should not try and delete
anything through these relations.  Since we don't have an easy way of
enforcing that, just have ActiveRecord use custom SQL that does nothing
when it is asked to delete a row in node_role_all_pcms.
Use wants-attrib to resolve attributes for jig runs.

This adds logic to stage_run in the top-level that unifies how
attributes are picked for a jig run.  The attribute-picking logic works
as follows:

1. Find all the wanted-attrs that the current noderole wants.  Right now,
   this is exactly equivalent to the set of wanted-attrs that the role
   associated with the noderole wants.
2. Split the list found in step 1 into attribs that will come from the
   node vs. ones that will come from the noderoles.
3. Resolve the attributes that come from the node object, and put them
   in the blob of JSON that will be passed into the actual jig run.
4. Get the combined attributes for all the parent noderoles on the
   same node, and add them to the blob of JSON.  We arguably should
   not do this, but the network roles need this to function properly.
5. Resolve all of the attributes that need to come from a noderole by
   finding the closest parent noderole that provides that attribute
   and extracting it from there.  We take care to respect the implicit
   flags of the roles involved -- if the role that attribute is
   provided by has the implicit flag, we make sure that it comes from
   a noderole bound to the same node as the noderole we are staging.
6. Add all the attributes from the current noderole.
Add a model to track user, system, and wall data for noderoles.

This allows us to relax the coupling between noderoles and snapshots,
which reduces the overall complexity of the noderole graph.

Before this change, creating a new snapshot for a deployemnt would cause
us to duplicate sections of the noderole graph, leading to an
accumulation of garbage in the node_roles and node_role_pcms tables that
we then had to have logic to skip when we wanted to perform calculations
on the noderole graph.  The reason we did this was to track changes in
user data over time.

This change extracts the userdata, systemdata, and wall fields of the
node_roles table into their own table, and fixes up the noderole logic
to refer to the new table.  The new table is curently treated as
append-only -- any change to a noderole's wall, sysdata, or user data
saves a new record with the updated data and points the noderole at that
one instead.
Merge pull request #830 from VictorLowther/pull-req-master-dccf04341e8a02b81a47fd321efe6c0256033410

+2 CB 2: Make all the things use wants-attrib for smart attribute injection. [1/8]
(for the record, I'd rather have migrations for tables in their own files but this is acceptable)