Fix/294 field name conflicts

[rebeccaskinner]

Addresses #294

NB: This patch should fix the bug in #294, but there is still room for greater discussion around how we access fields from other nodes. We can discuss here before merging, or merge and add an issue for refactoring the way that this works when we have a clear way forward.

The specific behavior we will now observe for exported field names is:

1. Names from anonymous structs are exported. For example we may
   access b.Foo directly when given a b of type B as show below:

   type A struct {
     Foo string
   }
   type B struct {
     A
   }
   

2. Named fields supercede fields exported by embdded structs. For
   example, calling b.Bar in the example below would return b.bar not
   a.b.bar

   type A struct {
     Foo string
     Bar string
   }
   type B struct {
     A
     Bar string
   }
   b := B{A: A{Bar: "a.bar"}, Bar: "b.bar"
   

3. Fields in an anonymous struct MAY be accessed by their type name.
   In the example above we may call b.a.bar which would give us
   a.bar. Likewise it is valid, but unnecessary, to reference Foo by
   calling b.a.foo.

4. Overlapping fields are not exported, but do not result in an error.
   In the example below, an error would be generated only when attempting
   to access a.foo, however we may access a.bar

type A struct {
  Foo string
  Bar string
  Foo string
}

1. If multiple structs are embdded, and their fields would overlap,
   they will not be exported directly, they may however be accessed using
   their field type name as shown in (3). In the example below a.b.foo
   and a.c.foo are valid, but a.foo is not.

type A struct { Foo string }
type B struct { Foo string }
type C struct {
  A
  B
}

[BrianHicks]

LGTM on green