Commit 3154794d broke the HTML report
when older some versions of pystache is used.  The current status is
that the HTML report generated on those systems is a one line report
containing the literal `utf8` string.

This proposal does not try to add support Unicode based inputs with
that version of pystache, because it's internally not well supported.
Internal methods such as `Template.render_tags()` will blindly try to
do conversions without respecting the encoding passed on `render()`.

Also, it's true that we're missing Unicode support in many other
places, such as documented here in this card:

 https://trello.com/c/bfE9NBbl

For now, let's try properly generate the report, and keep the error
handling already present, that let's users know there have been
encoding errors.

References: https://trello.com/c/8j3aVUlISigned-off-by: NCleber Rosa <crosa@redhat.com>

Added version file and updated the respective files

Signed-off-by: NCleber Rosa <crosa@redhat.com>

Now that the avocado package has been given a proper unique name,
that is, avocado-framework, we can define it as a requirement for
external and optional plugins.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The "Result" plugin interface was defined a while ago, and we now have
three implementations (JSON, XUnit, HTML).

Let's include them in the plugin listing, that is, when a user calls
`avocado plugins`.
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The method `logdir` is not used anywhere in the template, nor in the
plugin itself. I tried to find any occurrences and also setting a
breakpoint without any use whatsoever. Let's remove it.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

No actual changes, just style fixes.
Signed-off-by: NLukáš Doktor <ldoktor@redhat.com>

This step makes the HTML result a proper Python plugin, by living
outside the Avocado package namespace.

The RPM package is also adjusted: it now builds ands install both
Avocado and the HTML result plugin while keeping the two separate
installable packages.

Developers can use the usual `make link` and `make clean` to enable
and disable all plugins (including this one).
Signed-off-by: NCleber Rosa <crosa@redhat.com>

The goal of the `optional_plugins` directory is to hold all plugins
that ship with Avocado, but are not considered core functionality.
Plugins that are considered to be core still live under
`avocado/plugins`.

This also adds all directories to be found under `optional_plugins` to
the list of candidate plugins when running `make clean` or `make
link`.
Signed-off-by: NCleber Rosa <crosa@redhat.com>