New: Mark optional parameters (fixes #186)

[Pajn]

I choose to avoid storing optional: false to avoid a giant mess of failing tests, as undefined is false the use case still works.

[eslintbot]

LGTM

[soda0289]

Are there other cases where we need this:
What about interfaces:

interface foo {
	bar?: string 
}

or classes

class foo {
    public bar?: string
}

[Pajn]

We would need everything to be able to print the AST back to source. This was just what I encountered but to avoid a bunch of PRs to extend that if I can try to lookup and fix other cases. Apart from those two, properties in type object literals come to mind as well but I guess there can be even more.

[eslintbot]

LGTM

[Pajn]

I think I have gotten all cases, however the SyntaxKinds does not align perfectly with the spec so if you think of any other case to test please alert me.
Type aliases initializers goes trough the same path as type annotations so I didn't add en explicit test for those but can of course do so if you prefer.

[JamesHenry]

I think this is good for now. I will likely refactor this a bit in a future PR to have consistency around the optional property (i.e. add the optional: false to other tests)

[JamesHenry]

Blast, this was out of date with master and has caused an issue with the new optional params. I will submit a fix. I thought github repo was configure to block situations like that

[JamesHenry]

Purely a test output that needs updating, no functional regression

[Pajn]

I can rebase the PRs on each other if you prefer. Just tell me which and in what order.

[JamesHenry]

We'll just rebase each PR against master ahead of merging

[platinumazure]

@JamesHenry Another possibility is re-trigger the Travis PR build before merging a PR if you had merged a few other PRs before getting to that one- Travis will run the PR against latest master.

[JamesHenry]

Good point, @platinumazure! Thanks