Allow literal initializers of readonly properties in declaration files

[weswigham]

And use them in declaration emit when required to preserve the widening behaviors of certain literal types.

Fixes #15881

Note: This also normalizes where the error span is placed for the ambient initializer error between variable declarations and properties - it is now always on the expression, rather than split between the expression and the = token.

[sandersn]

One refactoring comment to address before checking in.

Also, for an old PR like this, you should probably merge from master before merging to it. I forgot about this last week and broke the build.

[sandersn]

I'm pretty sure you can move this inside the preceding if, as well as const isConstOrReadonly = ... above.

Then it would be worthwhile to invert the node.initializer check and return early.

[sheetalkamat]

How is this readonly declaration?

[weswigham]

It's not, the error span location was just normalized for the initializer forbidden error to always be on the initializer instead of sometimes on the initializer and sometimes on the equals token.

[sheetalkamat]

@weswigham makes sense. Sorry somehow I perceived as error removed. My bad.

[jacobdr]

@weswigham Thanks for the feature. Any chance you can take a look at this issue of ours and offer some advice on what you think is the best way forward?

[carpben]

Issue #15881 talks about type widening of readonly properties in classes. Will this PR solve the widening of readonly properties of object literals as well? For example:

interface IColors {
    readonly [k:string] : string
}
const COLORS : IColors = {
    red: "#f00"
}
interface IBasicReduxAction = {
    readonly type: string 
}
const someAction: IBasicReduxAction = {
    type:"SomeActionType"
}

After this release should the type of COLORS.red be recognized as "#f00" and the type of someAction.type be recognized as "SomeActionType"?