Typescript functional test runner improvements

[vitalics]

Describe the feature:
I suppose that time to describe typescript supporting and paths system, since it possible to faced with path hell like ../../../../myModule/myFile
Describe a specific use case for the feature:
let's describe all changes that could be approved by platform and QA teams. Here the list of changes:

1. typescript support (for type checking) ()
2. relative paths. My propose is using test folder as root (also probably include functional_test_runner folder which locates in src directory)
   In this case in some_test.ts file first line(after the license of course 😊) could be like that

import { TestWrapper } from 'typings';
export default function( { getPageObjects }: TestWrapper ){ /* code here */ }

or new typings from #31948:

import { FtrProviderContext } from 'typings';
export default function( { getPageObjects }: FtrProviderContext){ /* code here */ }

As for me it's more simplify and understandable than this line

import { FtrProviderContext } from '../../../typings'; // so long path 😓
export default function( { getPageObjects }: FtrProviderContext){ /* code here */ }

Also, I attached current progress about tests and typescript:
#31948 #32038 #31234

Update: One more proposal is extending tslint from root for disabling export default(any tests are default exporting functions and better solution is disable this rule)

[spalger]

Personally, I strongly dislike anything that rewrites import statements and it's something we're trying hard to get rid of in webpack because we find it really hard to know where the code you're actually importing lives. In other cases though it is really nice to have a global namespace that you can store things that are used all over the place, kind of like a node_module, which we have packages for.

I did this in #31948 with the @kbn/test/types directory, @kbn/test is a package and installed as a node_module so we can import it with the @kbn/test name anywhere in the code. This is my preferred way of "aliasing" bits of code, rather than using something like tsconfig-paths

[vitalics]

Agreed with @spalger about tsconfig-paths lib
Also, I contemplate about page object implementation in the kibana. And maybe we should implement component-page-model architecture?
Page is a class/function which has the url only. E.g. visualize is a page since has the url like this: <baseUrl>/app/visualize
This page contains a lot of components such as Visual builder with subComponents: Time Series, Table, Markdown, Gauge(see the screenshot below. Red squares is a subcomponents which also can include other components)

How provide some data in the component? Model is a entity with predefined values(e.g. which data should be provided). E.g.(or something like this)

namespace VisualBuilder {
  interface MarkdownModel extends Model {
    foo: 'foo',
    bar: 'bar',
  }
  interface TimeSeriesModel extends Model {
    baz: 'baz'
  }
}

[spalger]

I personally prefer using services for reusable components, like the appsMenu service. This component lives on any page and the use of a service doesn't imply that it is a page. The methods it defines are pretty simple, since there is only one appsMenu in Kibana, but for more reusable components it would probably make sense for each method to take a "test subject" that points to the container for the component.