Destructuring

This pull request adds support for ECMAScript 6 destructuring declarations and assignments with down-level ES3 and ES5 code generation. For example:
```typescript
var [x, y] = [10, 20];
[x, y] = [y, x];
```
The above example generates:
```javascript
var _a = [10, 20], x = _a[0], y = _a[1];
_b = [y, x], x = _b[0], y = _b[1];
```
Another example:
```typescript
interface NameAndLocation {
    name: string;
    location: [number, number];
}

function getNameAndLocation(): NameAndLocation {
    return { name: "top-left", location: [10, 20] };
}

function displayNameAndLocation({name, location: [x, y] = [0, 0]}: NameAndLocation) {
    console.log("name=" + name + " x=" + x + " y=" + y);
}

var {name, location: [x, y]} = getNameAndLocation();
displayNameAndLocation(getNameAndLocation());
```
The above example generates:
```javascript
function getNameAndLocation() {
    return { name: "top-left", location: [10, 20] };
}
function displayNameAndLocation(_a) {
    var name = _a.name, _b = _a.location, _c = _b === void 0 ? [0, 0] : _b, x = _c[0], y = _c[1];
    console.log("name=" + name + " x=" + x + " y=" + y);
}
var _a = getNameAndLocation(), name = _a.name, _b = _a.location, x = _b[0], y = _b[1];
displayNameAndLocation(getNameAndLocation());
```
Work still remaining:
* Support for rest elements in array destructuring.
* Pure ES6 code generation with no rewriting (under -target ES6 switch).
* Updated spec.

Note: passing this 'kind' down through the pattern concerns me.  There are several issues that make this problematic.

1) Parsing of nested constructs is dependent on a top level value passed downward.  In general we try to avoid this as it can affect incremental parsing.

2) It doesn't actually seem necessary.  This is only passed down ```var node = <BindingElement>createNode(kind);```.  However, it's unclear to me why we need those individual nodes to have the kind .Parameter or .VariableDeclaration, instead of being just .BindingElement's.  If later phases of the compiler need to know/care that this is a binding pattern in a 'Parameter', then they could just walk upwards till they find the relevant parenting ParameterDeclaration or VariableDeclaration.

This is similar to what we do in all sorts of places in other parts of the compiler already.  

3) It forces you to make a function expression allocation in ```parseBindingList```.  I just went through and removed all function expression allocations from the parser (including during speculative/lookahead parsing) and it would be nice to not reintroduce that if it's not necessary.