Add support for controlled trailing semi-colons and injecting custom properties

[manikandan-ravikumar]

In this PR, I would like to introduced the following two new settings,

1. disableTrailingSemiColon - A boolean flag indicating if the generator should append every line with a semi-colon
2. injectCustomProperties - A map of class to string property lists. Similar to importDeclarations but instead injects additional properties into the given type. This is useful for when we try to be backward-compatible in the FE API and update the backend logic to have the newer property names. Also avoids adding these properties manually every time after running the typscript-generator.

This PR also includes some minor improvements in other parts of the code.

[panchenko]

@manikandan-ravikumar Could you please elaborate on the reasons for disableTrailingSemiColon?

[manikandan-ravikumar]

@panchenko I am not disabling semi-colons. I am just introducing an option to disable it. The default value for disabling semi-colon is false.
The reason behind this is, not all typescript projects use the trailing semi-colon pattern as with JavaScript/Typescript semi-colons are optional. Providing an option to disable it will avoid unnecessary manual work.

[panchenko]

This task is setup in build.gradle, but the corresponding user-defined classes are not accessible there.
Should be class name as string - similar to other fields.

[manikandan-ravikumar]

Addressed this comment

[panchenko]

The reason behind this is, not all typescript projects use the trailing semi-colon pattern as with JavaScript/Typescript semi-colons are optional. Providing an option to disable it will avoid unnecessary manual work.

I am trying to understand why it matters. Code analysis should be just disabled for the generated file. For example, in the file header there are comments to disable tslint/eslint.

[manikandan-ravikumar]

The reason behind this is, not all typescript projects use the trailing semi-colon pattern as with JavaScript/Typescript semi-colons are optional. Providing an option to disable it will avoid unnecessary manual work.

I am trying to understand why it matters. Code analysis should be just disabled for the generated file. For example, in the file header there are comments to disable tslint/eslint.

I agree from the functional POV. But from code maintenance POV, it makes this file stand-out. I am working in a project where we maintain a common standard across the code base and it involves no semi-colon usage. So, we had to generate.ts and make manual changes on top of it every time. This breaks the concept of having a "generated" file.