The configtx code uses an 'append(...)' against a slice, and records the
new slice address when computing the config map.  Through sheer dumb
luck, this code works for config groups which are only nested 2 levels
deep, because the append call triggers a true new memory allocation.
However, for config groups 3 levels deep (such as consortium groups),
the append call actually re-uses the underlying memory for the slice.

This causes the path to be corrupted internally for the consortium group
items, and cause the wrong policy to be resolved when checking for a
policy which has been specified relatively.

This fix manually allocates new memory, copies it, and then appends the
element.

Change-Id: I0f4df619e006cdfebba60173156bda597d42a544
Signed-off-by: Jason Yellick <jyellick@us.ibm.com>