[APM] Migrate to Typescript and refactor backend apis

[sorenlouv]

Extends the work done in #25514

Prefer unknown over any

TypeScript 3.0 introduces a new top type unknown. unknown is the type-safe counterpart of any. Anything is assignable to unknown, but unknown isn’t assignable to anything but itself and any without a type assertion or a control flow based narrowing. Likewise, no operations are permitted on an unknown without first asserting or narrowing to a more specific type.
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-0.html

Force explicit return type when using "blackbox" clients
"Blackbox clients" is a term I used about clients where the return type cannot possibly be inferred in compile time. This is the case with the http client, ES client and config manager, that all currently have any as return type. This means that the user is able to access properties and methods that might or might not exists, without any warnings. Example with the ES client:

const response = await client('search', esParams);
response.foo.bar.baz; // no error or warning. The return type for `baz` is also `any`

To highlight this issue I've made all clients generic, so they accept a return type. The default return type is void:

const response = await client<Transaction>('search', esParams);
response.foo.bar.baz; // Error, not available on Transaction
resp.hits.hits[0]._source.transaction.id // Works, and `id` is typed according to the `Transaction` interface

Types for chart
Both the backend and frontend code the charts was in js and has been migrated to ts

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[sorenlouv]

retest

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[jasonrhodes]

• For the API response types, do you want to stick with the I prefix?
• I like the fetch/transform abstractions, on the fence about whether to pull fetch stuff into the index files or not. If we keep them separate, can we either have fetch/transform or fetcher/transformer for the file names? (I think I prefer fetch/transform but either way.)

Otherwise I think this LGTM

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[sorenlouv]

retest

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request