hotsos/core: add name aliasing support

[mustafakemalgilor]

at the moment, scenarios are using the long import paths in order to reference to a Python property. this feature allows assigning an alias to a Python class or variable in order to make using plugin property interfaces easier.

Added aliases to the plugins. Updated existing scenarios to use aliases.

Fixes #912

[mustafakemalgilor]

The aliasing naming seems a bit odd to me. For example, juju.base, kernel.calltrace, 'ceph.daemon.all-osds` and so on give the impression it's a package/class hierarchy when they are just a given name.

Given we could mix with the original way of writing/accessing the properties, the use of dots seems a little misleading.

The dot separation represents a hierarchy, where the first part is the plugin name, then the optional subsections, and finally the property name. I made it this way so if we write a YAML schema(*another important QOL improvement that will make it easier to write scenarios) for the scenarios for IDE/editor assistance in the future, it would be convenient for tab completion.

As for the possible confusion, we can easily distinguish an alias from the full path as the package names always have to start with hotsos. (*unless we start supporting external plugins), so if it starts with "hotsos", it's a full property path, otherwise, it's an alias.

[pponnuvel]

The dot separation represents a hierarchy, where the first part is the plugin name, then the optional subsections, and finally the property name.

Now you say that, it makes sense. But it's not obvious otherwise. Also nothing prevents anyone from giving arbitrary names. So might be useful to have a section ("Alias naming") in documentation on the naming convention.

[mustafakemalgilor]

So might be useful to have a section ("Alias naming") in documentation on the naming convention.

Added a check for preventing an alias from starting with "hotsos.", added the "Alias naming" section to the docs, and also added some unit tests to verify all that.