Add new subcommand to help using stacks not managed by elastic-package

Problem statement
--

There are some use cases that require customizations of the elastic stack that elastic-package doesn't support. A relatively common use case is when developing features in Elasticsearch, Kibana or other internal components. Wwe could add more providers to `elastic-package stack up`, but this can be quite difficult to maintain, as each developer environment can have very different dependencies, and backwards compatibility may not be granted.

At the moment a common workaround for that is to set the related `ELASTIC_PACKAGE_` environment variables. But this is not very obvious and doesn't have such a good integration with other `elastic-package` subcommands.

Proposed solution
--
Add a new command that helps with the configuration of a profile to reuse an stack not managed by elastic-package.

It could be something like the following:
```
elastic-package stack import --elasticsearch-host http://localhost:9201 --kibana-host http://localhost:5601/xyz
```
This command would configure the profile so the `stack/config.json` file contains something like the following:
```
{
"provider": "import",
"elasticsearch_host": "https://127.0.0.1:9201",
"elasticsearch_username": "elastic",
"elasticsearch_password": "changeme",
"kibana_host": "http://127.0.0.1:5601/xyz",
"ca_cert_file": ""
}
```

A flag would exist for each of these variables with the usual defaults:
* `--elasticsearch-host`: `http://localhost:9200`
* `--elasticsearch-username`: `elastic`
* `--elasticsearch-password`: `changeme`
* `--kibana-host`: `http://localhost:5601`
* `--ca-cert-file`: `` (not set)

Ideally we should support other authentication methods like API keys, but lets leave this as a separate issue by now (see https://github.com/elastic/elastic-package/issues/1633).

We should check that elastic-package commands are able to work with this stack configuration:
* `elastic-package shellinit` should print the configured values.
* `elastic-package status` could check if services are reachable.
* `elastic-package test` should work.

Start by reading the existing `elastic-package stack up` command and the profile handling that writes `stack/config.json`. Then trace how `shellinit`, `status`, and `test` consume the stack configuration. Done means an import command accepts the listed connection flags, configures the profile, and those three commands work with the imported stack.

Written by the indexing model from the issue text.