Shall we diverge from TWS API?

[mfrener]

As @Tsopic mentioned #31 (and another user on a ticket already) Number.MAX_VALUE return values feel very strange in JS/TS.
The reason why we return Number.MAX_VALUE for "not available" attributes instead of 'undefined' is stay in-sync with official IB APIs.

This discussion is about if we want to diverge from official API, or if want to stay as close as possible.
Pros:

• We can leverage language / platform specific features. First and most obvious one is the 'undefined' instead of Number.MAX_VALUE, but there might be more we want to change (i.e. get rid of request IDs and EventEmitters and return rxjs Observables instead).

Cons:

• We will lose "compatibility" to any reference and/or code snipped on the official API.
• Upgrading to new TWS API versions will be become more difficult the more we diverge. Right now this 1:1 Java<->TS, not change in logic, you can even port w/o running the Java client. If we start to diverge, this will become more difficult as we might have other, or additional code-paths.

Up now, I opted to stay compatible.
Mainly because I knew the API already, so was expecting the Number.MAX_VALUE and because the old initial JScript fork was also using Number.MAX_VALUE .. and I didn't had time yet to think more about the implications of a change and or maybe even do on a "preview branch" :D

Let me know your opinion.