The type definition for ng.IPromise.then was, in my opinion, incorrect
semantically, and breaking on practical examples in my codebase.
An `IPromise`' `then` function takes a callback which is called with the
value of the promise once it's fulfilled. This could be a number, a
string, some object, an array of strings, anything really. Yet the
typing in angular.d.ts specified `then` as taking a `successCallback` of
type `(response: PromiseCallbackArg) => any`.
The definition of `PromiseCallbackArg` seems very permissive at first
glance, as it is defined to be an object with a bunch of fields, all
optional. Any object, a number, and a string all type check correctly
with such a type, but an array of strings, for example, does not
(`cPromise` in the provided list of test).
Furthermore, it seems to me that the `PromiseCallbackArg` definition was
added specifically to support the response type for promises returned by
the Angular `$http` service, the `ng.IHttpPromise`.
So instead of having an incorrect type on the `ng.IPromise.then` function,
I propose we return it to its generic form, and instead override the
type of the inherited `then` function in the `ng.IHttpPromise` interface.
This would also warrant renaming `PromiseCallbackArg` to
`IHttpPromiseCallbackArg`.
angularjs: docs around first page tutorials
jquery: fix for known lib.d.ts big
knockback: add typing for observable based on tutorial, add docs around
observable.
This enables each definition to have a readme if necessary.
Also a .json metadata file to help with package managers.
And last, to have different versions of the definitions.
