Remove "can.List.newInstance" attribute defs from Task objects

This fixes response options not saving when using menu or checkbox task types.

Technobabble below:
--------------
new can.List() takes nonnumeric indexed options as its second parameter.  In other words, can.List.setup() has the signature ```function(instances, options)``` and if you pass in an object after your source array, the object's properties will overwrite the ones that came from the array.  This leads to odd behavior like
<code><pre>> new can.Observe.List(["a", 'd'], "b")
["b", "d"]</pre></code>

What this actually means for us is this.  We were (read as "I was") using "can.List.newInstance" in the attributes descriptor for these objects for some reason lost to the annals of time; yes I know it was only last week.  Anyway, when doing a convert from attributes-defined functions, the previous value of the attribute is passed in as the second argument.  This means we got passed in:
<code><pre>elements: ['bart', 'lisa', 'maggie'],  //length: 3
options: can.List([]) //length: 0</pre></code>

I think you see where I'm going here.  The length got overwritten; even though the elements were there, they were ignored by $.map and by serialization and by the CSV converter compute because the length attribute of the can.List that came out was 0.

Why did it work during the demo?  My best guess here is that I was actually working from a TaskGroupTask where the existing value of response_options was null.  If the oldValue is null, it doesn't overwrite the length.  Et voila.