…d pointer types.

Prior to this change, the following code would panic the compiler:

```go

type (
	S  struct{ f int }
	PS *[]S
)

var _ = []*S{{}} // This compiles, but potentially incorrectly.
var _ = []PS{{}} // Compiler panics here.
```

Prior to this change, GopherJS compiler didn't expect that a pointer type could be named in this context, and would panic. This is addressed by checking the underlying type, rather than the type itself.

However, there was a bigger correctness problem here too. According to the Go spec:

> Within a composite literal of array, slice, or map type T, elements or map keys that are themselves composite literals may elide the respective literal type if it is identical to the element or key type of T. Similarly, elements or keys that are addresses of composite literals may elide the &T when the element or key type is *T.

So in the example above, `[]PS{{}}` expression is equivalent to `[]PS{PS(*S{})}`. However, even with the first part of the fix, the code emitted by the compiler would have been equivalent to `[]PS{S{}}`. This mostly works because at runtime GopherJS represents a pointer to the struct and the struct type as the same JS object, but it would break down when it comes to methods and non-struct types. So the second part of the fix is to generate the explicit AST for taking an address of the value type and type conversion, and compiling that.