Define protocol for porting abstract classes from .NET to TypeScript

[stevengum]

IMHO - it is fine to have an abstract base class for providing default implementation shared across derived classes. However, I don't think this has to mean removing the interfaces. By removing the interface, the other classes become dependent on a specific implementation. Interfaces do a good job of defining the contract in Typescript and get compiled away. There aren't the same tradeoffs between ABCs and interfaces like there are in .NET.

Originally posted by @GeoffCoxMSFT in #2342 (comment)

I agree with Geoff's PR feedback on #2342. If there are implementations that should be default, then an abstract class is valid in TypeScript (TypeScript does not have default implementations available via interface like C#).

However, as he indicates, there are language differences that need to be taken into account when porting abstract classes into TypeScript. The point about TypeScript interfaces is especially poignant as TypeScript is a superscript layered on top of JavaScript.

While this may be more in the vein of a "'magic wand' ask" ideally, any abstract classes with provided functionality should be nigh-close to perfect, otherwise we run overload and method deprecation issues experienced in Skills in TypeScript.

We should define a protocol for porting over abstract classes and interfaces from .NET to TypeScript.

[joshgummersall]

Deliverables would include linting and a documented guideline that lives somewhere.