Build kbn packages with bazel build POC

[mistic]

One of the steps of the POC described on #69706 is to build the kbn packages with bazel. That issue will be used to track the progress of that mentioned experimentation.

[elasticmachine]

Pinging @elastic/kibana-operations (Team:Operations)

[mistic]

At this point I have a base BUILD file written for every package that will probably would have the need to evolve along the process.

Below I want to list some of the decisions of this process so far:

• use ts_project to build typescript projects instead of ts_library. The latter can offer more performance but it introduces technical trade-offs that we don't want to take right now. However we can re-evaluate them on the future
• a pkg_npm target with the name npm_module will always be created for each package in order to create a point of interaction between the bazel-bin and the legacy build system that only relies on the workspace state itself.
• I've migrated the repo to be able to rely only in the top level package.json listed dependencies as Bazel so far only supports this. It's very likely in the coming weeks or a couple of months bazel starts supporting yarn workspaces.
• a .bazeliskversion and a .bazelversion were created on the repo and those are the ones responsible for setting the version management of bazel itself.
• @kbn/pm was changed for now to only run bazel build //packages:build instead of running bootstrap scripts for each package. The only exception is the kibana project itself because it needs to register the pre-commit hook.

Problems we are dealing with for now:

• The major problem at the moment is to be able to universally depend and require first party packages by name. After discussing some alternatives with @tylersmalley we've decided to try to implement a new rule called js_library to suite those needs we are having.

[spalger]

• @kbn/pm was changed for now to only run bazel build //packages:build instead of running bootstrap scripts for each package.

This means we won't have things like source maps support for local development, would you mind swapping out for the bootstrap script vs the build script if we have to choose one?

[mistic]

@spalger what I have been doing so far is generating the production targets (usually found under build scripts) but always produce sourcemaps and types (if that is the case). Do you think is that okay?

[spalger]

always produce sourcemaps and types

Sounds good to me

[mistic]

At this point in the context of the POC I think we already did a lot on testing to build kbn packages with bazel. More updated and explaining information could be found in the last update on #69706 (comment)