Following discussion with @neelance and @shurcooL

This proposal is a follow on from #633, that is to say, please read this proposal as if #633 has been approved, implemented and merged.

Consider the following *js.Object-special struct type declaration:

type T struct {
	o *js.Object `jsspecial:"true"`  // tag name still TBC in #633

	Name     string `js:"name"`
	Age      int    
	location string
}

At present, as described in the wiki, when creating a value of type *T via a struct literal, you have to initialise the fields separately:

v0 := &T{o: js.Global.Get("Object").New()}
v0.Name = "Peter"
// ...

We propose that values of type *T can be created in either one of two ways:

1. &T{o: someO}
2. &T{Name: "Peter"}

The first case represents no change over the current situation.

In the second case, an Object is implicitly instantiated for us, so it's as if we'd written:

v := &T{Name: "Peter"}

// is equivalent to

v := &T{o: js.Global.Get("Object").New()}
v.Name = "Peter"

Note, by preventing a mixing of the two forms we remove any questions/ambiguity around order of evaluation etc. Mixing of the two forms would result in a compiler error:

v := &T{o: js.Global.Get("Object").New(), Name: "Peter"}  // ERROR

This proposal leans heavily on the discussion in #236 (thanks for raising @Archs and to @theclapp and others for the ensuing discussion)

The clearer semantics introduced in #633 make this proposal itself much clearer, but also allow for fluent, unambiguous use of composite literals for *js.Object-special struct types.