[Stack Monitoring] working with packages doc

[klacabane]

Summary

Added howto work with packages documentation

[elasticmachine]

Pinging @elastic/infra-monitoring-ui (Team:Infra Monitoring UI)

[tonyghiani]

Suggested change

The Stack Monitoring packages provide a similar experience as their beats modules counterpart, both for metrics and logs ingestion. Feature wise these two collection modes are used to provide the Stack Monitoring UI the data it needs to power each product views. There is a however a difference in how the data is stored: while standalone beats modules will store all their data in a single data stream, for example `.monitoring-elasticsearch-8-mb`, the integrations will create one data stream for each metricset or filestream, for example `metrics-elasticsearch.stack-monitoring.node-default` for the node metricset. This means the integrations mappings are more specialized because they're split to only define the relevant properties for each metricset but the merged version of an integration data streams should be equivalent to its metricbeat mapping.

The Stack Monitoring packages provide a similar experience as their beats modules counterpart, both for metrics and logs ingestion. Feature wise these two collection modes are used to provide the Stack Monitoring UI with the data it needs to power each product view. There is however a difference in how the data is stored: while standalone beats modules will store all their data in a single data stream, for example `.monitoring-elasticsearch-8-mb`, the integrations will create one data stream for each metricset or filestream, for example `metrics-elasticsearch.stack-monitoring.node-default` for the node metricset. This means the integrations mappings are more specialized because they're split to only define the relevant properties for each metricset but the merged version of an integration data stream should be equivalent to its metricbeat mapping.

[tonyghiani]

Suggested change

	A package can define the services it needs to monitor for development and automated testing purposes, for example the mysql package needs a running database to fetch and validate metrics or logs. While we could use the elasticsearch and kibana services started by `elastic-package stack up` we don't want the stack packages to be special cases and just like mysql, the packages should be responsible of defining their dependencies.
	This can be done by creating a `docker-compose` file under the package `_dev/deploy` directory, then running `elastic-package service up -v` in the package folder. An example is the [elasticsearch package](https://github.com/elastic/integrations/tree/main/packages/elasticsearch/_dev/deploy/docker) that starts a service which generates every types of logs with the help of a script executing queries.
	A package can define the services it needs to monitor for development and automated testing purposes, for example, the mysql package needs a running database to fetch and validate metrics or logs. While we could use the elasticsearch and kibana services started by `elastic-package stack up` we don't want the stack packages to be exceptional cases and just like mysql, the packages should be responsible for defining their dependencies.
	This can be done by creating a `docker-compose` file under the package `_dev/deploy` directory and then running `elastic-package service up -v` in the package folder. An example is the [elasticsearch package](https://github.com/elastic/integrations/tree/main/packages/elasticsearch/_dev/deploy/docker) that starts a service which generates every type of log with the help of a script executing queries.

[tonyghiani]

Great explanation here 👏
My browser just passed the text with the Grammarly extension and found a couple of typos, I marked them as suggestions, but overall the content LGTM 👌