Revisit integrations' dashboards and visualizations naming conventions

Currently dashboards and visualizations of packages follow almost the same [naming conventions](https://github.com/elastic/beats/blob/main/docs/devguide/newdashboards.asciidoc,) as in beats .

There is this [guide](https://www.elastic.co/guide/en/integrations-developer/current/create-dashboards.html#_naming) that package developers follow.

These conventions are:
- Dashboard names have prefix `[ ] `, e.g. [Metrics Kubernetes] Cronjobs
- Visualizations and searches have suffix ` [ ]`, e.g. CronJobs Informations [Metrics Kubernetes]

As mentioned in https://github.com/elastic/kibana/issues/67258 this is done mainly for organizational reasons, so that the customers can find the dashboards and visualizations they want among multiple.

With the new features of Kibana like saved object tagging (https://github.com/elastic/kibana/issues/74571) we could use tags for the dashboards instead of the prefix.

Also regarding the visualisations, it seems even simpler.
Migrating visualizations to [by value ](https://github.com/elastic/integrations/issues/3448) practically means that individual visualizations are not saved as separate objects in Kibana but only as part of the dashboard.

So it does not seem to be any strong reason why the visualizations should have a suffix.

This was important when all those visualizations were saved as objects and some could have the same names(coming from different dsahboards) which could cause conflicts and confusion.

In general those extra suffixes and prefixes create noise and may also make the titles really long and not readable.