[meta] Path to elastic-package 1.0

At some point we should consider `elastic-package` ready to have a 1.0 version. Let's create a checklist of issues to solve before releasing a 1.0. To decide if something should be done before or after 1.0, think if doing it may introduce breaking changes.

Releasing a 1.0 basically means that we consider `elastic-package` stable and mature, and we have to be even more considerate with introducing breaking changes.

If we expose something as Go package, we should review also that we are happy with the provided API, but I think we don't expose anything like this here.

Checklist:
* [x] Fully remove deprecated commands related to storage v1 https://github.com/elastic/elastic-package/pull/2248 https://github.com/elastic/elastic-package/pull/2335
* [ ] Fix issues and redefine profiles and configuration files. Decide what is internal and what is user config. Decide what persists between upgrades and stack operations.
* [x] https://github.com/elastic/elastic-package/issues/962
* [x] https://github.com/elastic/elastic-package/issues/558
* [x] https://github.com/elastic/elastic-package/issues/557
* [x] https://github.com/elastic/elastic-package/issues/361
* [ ] https://github.com/elastic/elastic-package/issues/398
* [ ] https://github.com/elastic/elastic-package/issues/507
* [ ] Improve testing coverage (not breaking change, but related to stability/maturity).
* [ ] https://github.com/elastic/elastic-package/issues/912
* [x] https://github.com/elastic/elastic-package/issues/732
* [ ] https://github.com/elastic/elastic-package/issues/555
* [ ] Fix issues related to build
* [ ] https://github.com/elastic/elastic-package/issues/1156

Start by reviewing the unchecked checklist items, especially issues #398, #507, #912, #555, and #1156, and use the completed items as context. Done means resolving or explicitly deciding the remaining configuration, testing, and build concerns so the project can assess readiness for a stable 1.0 release.

Written by the indexing model from the issue text.