Also, factorise code.

This is fuxip for 1038d441

Quick way to isolate tests

getInstalledBusinessTemplate was returning "replaced" versions of a business
template beeing uninstalled.
Also add some missing tests for getInstalledBusinessTemplate

Likewise for positional REQUEST parameter.

Also, extract unwanted kw entries by just declaring them as separate
parameters.

It is not passed a value, so DTML walks acquisition path (and skins) on
each call (which do not pass from_expression).

This reverts commit 0fc02acc.

selection_report is actually a legal ZSQLCatalog parameter.
selection is not, but there are more instances of its usage, so cleanup
will be in a separate commit.

This way, it becomes pretty easy to add matrix functionnality to any portal
type TTW

The business template does not set ERP5 enough for proper indexation in
email table. Given the low popularity of this business template, mark its
test as expected failure with explanation.

https://git.erp5.org/gitweb/jio.git/blob/refs/tags/v3.3.0:/dist/jio-latest.js

local_roles is handled entirely inside ERP5Catalog, so to not tell
ZSQLCatalog about it - it can do nothing right with it anyway.
Also, get rid of abusive **kw use in this code path.
Also, actually pass sql_catalog_id to getAllowedRolesAndUsers.

This is at least needed for
  external_account_interaction_workflow/scripts/Career_start
as it filters by "email.url_string".

This parameter is handled nowhere in ERP5 and ends up passed to catalog,
which complains about it.

This is needed for (at least part of) Alarm_activateCheckConsistency
functionality.

Avoids giving catalog parameters it cannot handle and would complain about.
Reviewed-By: Julien Muchembled <jm@nexedi.com>

Also, replace one more use of getResultValue in favor of explicit list
unpacking, as getResultValue does not complain in face of multiple results.

So use destination_uid as it is the most efficient approach.

Mixing states from unrelated workflows produces output which becomes hard
to understand. As a result, it was removed from Folder_viewWorkflowReport
and must not be expected by test.
Also, because of implementation detail, section order changed, so update
indices.

It is dangerous to rely on SKINDATA, as its structure changes. There is no
better solution here, so continue using it - just make it more prone to
raise rather than accidentally using the wrong item (3-tuple became a
4-tuple by prepending a single item, so [0] would return the wrong item).

Patched class' getCurrentSkinName expects a 4-tuple, although it ignores
the first value, so provide a placeholder.