Various eslint-suggested fixes

[lhstrh]

          Yes and no - I made sure `eslint` won't complain, but some are simply suppressed by `eslint-disable-next-line` and added as TODO items.

Here are some examples:

• @typescript-eslint/no-this-alias is suppressed entirely; it is addressed in Possibilities of eliminating binding workarounds #159
• Some Java style code that does not live well with ts, for example, empty abstract class and classes with only static methods

• reactor-ts/src/core/port.ts

  Lines 90 to 99 in 6db9fb0

  	interface IOPortManager<T extends Present> extends TriggerManager {
  	// TODO (axmmisaka): Function property is better in terms of type checking
  	// as tsc will check additional info; yet that additional check will cause massive issues
  	// and therefore this linter rule is disabled and method signature is used.
  	// However, this indicates that there are typing issues and needs to be addressed.
  	// eslint-disable-next-line @typescript-eslint/method-signature-style
  	addReceiver(port: WritablePort<T>): void;
  	// eslint-disable-next-line @typescript-eslint/method-signature-style
  	delReceiver(port: WritablePort<T>): void;
  	}

  ; if this is changed the whole reactor.ts will explode
• We have a lot of use of any and maybe there could be alternatives (mostly solved by Improved typing #172 and Remove Present and replace with unknown; remove Args and Trigger and use TS Tuple #168)

Yet I think these changes will involve complex refactoring and should be addressed in individual issues

Originally posted by @axmmisaka in #160 (comment)