Using Image Document, this commit includes tests to assert
the conversion outcome when convert svg to png. The main goal
is assert if the image backgronud (external and embeded cases)
is incorpoted into the PNG generated.

The image comparation is very basic level, but enough for this tests.

It exposes an error when convert one svg that uses url with http.

In order to fix content type it was Introduced a small
Monkey-Patch for zope.contenttype in order to detect
image/svg+xml content types. This is broken even in newer
versions and this monkey patch is foward compatible.

Update Document and tests to permit conversions to SVG, this
prevents get Unauthorized when use ?format=svg.

If one Activity Failure happens during the functional test, the
error message was not clear enough to identify why the activity
failed.

This change is minor and do not change the final outcome. The
intention is make Runner less dependent of the erp5 portal itself.

It is required use Security Category Mapping Configurator Item at the
consulting workflow, like it is done at Standard workflow.

Change listbox to get the start_date from movement because the start_date is updated when the object is created. To be possible display the datetime customized the listbox_delivery_start_date was renamed to listbox_movement_start_date to follow the column used. One test was updated because name of the tag was changed

When the same document is uploaded,  the message displayed after upload is different. So, the code was changed to check the url without the parameters.

Use a much wider range for Accounting Period definition to prevent
random errors when define dates at the test.

The related tests were updated for check this change.

The reusage permit use configuration for multiple gap
definitions. Included specific test for Account Configurator Item.

This Constraint do not work for packing lists because according to
the constraint the "lines" should be order movements and not delivery
movements. Update related Test.

This keeps compatibitility with Standard Configurator outcome.

Test were updated to check the change.

The test should be compatible with Configurator Outcome and w/o
Configurator case. This change unify outcome of those 2 cases,
making it compatible when run into diferent scenarios.

This Configurator Item configures the script ERP5Site_getSecurityCategoryMapping, This can be
combined with roles generations and categories spreadsheet in future to generate full security
definition.

Update configuration to use Security Category Mapping Configurator Item instead include the
script directly, otherwise it breaks the instance due the dependency with scripts on erp5_dms

Initial code is almost the same as the one provided by erp5_simulation_test
in order to preserver initial compatibility

Those functional tests also need those business templates with the code
previously on erp5_simulation_test

Include base categories copied from erp5_trade in order to
drop installation dependencies. This permit the configurator
test become more accurate with the desired result.

Use sale trade condition from configurator or create a very
similar one. Do not use path to this in order to prevent
this business template depends on others bt5s.

Clean up some paths (**) which were useless (it adds nothing).

Due simulation alarms some simulation related objects (ie.: Sale Packing Lists) are
owned by __erp5security-=__ user during the functional tests. In this case, this
script also consider those objects "safe" to remove (as the tests uses very strict
search).

As funcitional tests runs with alarms disabled, invoke alarms is needed
for make simulation work. This commit also includes a macro.

This change may help us to understand why the build is stalled when
an error page is showed to the user.

See commit 954c7989

Previous implementation only considered workflows that are chained to the
portal type:
- this is slower
- modification_date of old documents may change or disappear, preventing their
  reindexation
- edit_workflow was always considered, regardless it is chained or not

This commit makes getModificationDate more consistent: it simply iterates over
all workflow histories stored on the object.

When there is no workflow history, ZODB date is returned, which makes
getModificationDate useful for objects without any workflow chained, like
simulation movements.

Another optimization is that last history entry is accessed without loading
the whole history.