fix #14559 - Filter for adm_report_config.php

Signed-off-by: Damien Regad <damien.regad@merckgroup.com>
Issue #14559: improve adm_report_config.php filter

The following changes were made

- revised UI to make it more similar to the issues filter
- make use of existing constants and language strings
- filter defaults to All Users / All Projects / All options which avoids
  performance issues in installations having a large number of entries
  in the config table (workaround for issue #13680)
- filter form uses post instead of get method
- comply to coding guidelines
Localisation updates from http://translatewiki.net.
Localisation updates from http://translatewiki.net.
Make it possible to edit config options in adm_config_report.php

Use CONFIG_TYPE_xxx constants instead of magic strings to define the
type of config value to process.

Added code for FLOAT type which was previously handled through COMPLEX.

Improve handling of INT (and FLOAT) by calling constant_replace(),
allowing user to specify a defined constant instead of a numeric value.

Fixes #7586
Localisation updates from http://translatewiki.net.
Standardize the copyright notice

To facilitate the process of bumping the copyright year, this commit unifies
the way the copyright statement is written throughout the code.
Update copyright year to 2013
Use date() for current copyright year in html_footer
Split very long echo statement on multiple lines
Revised Cookies documentation

- Removed paragraph with incorrect information about need to redefine
  cookie variables after modifying $g_cookie_prefix.
- Revised layout
- Updated description for some variables
- Reflected these changes in related comments in config_default_inc.php
Fix 1st uppercase letter for 'Filters' language string

Affects issue #14559
Respect $g_show_realname setting in config report's filter userlist

The filter's original implementation displayed "Realname (username)" in
the user selection list. We now only retrieve the user id from the db,
and call user_get_name() to get either the realname or the username as
appropriate instead.

Issue #14559
Manage persistency of config report filter using a cookie

A new cookie 'manage_config_cookie' was added to store the user's filter
criteria.

Includes documentation update to admin guide.

Issue #14559
Rename 'manage_cookie' to 'manage_users_cookie'

After the introduction of the 'manage_config_cookie', the name of the
existing cookie ('manage_cookie') which is used to store the filter for
the Manage Users page could be misleading, so it has been renamed to
'manage_users_cookie'.
Whitespace: remove unnecessary code indentation
Config report filter: added handling for invalid values in cookie

In some cases, the cookie could contain values which are no longer
applicable as filter criteria, e.g.
  - a project id which has been deleted
  - a user id for whom there are no config options
  - a config id for which there are no config options

The code now correctly handles these, by making sure that either the
filter criteria is dynamically updated to a valid value (ALL_PROJECTS
for projects), or the filter's selection list effectively includes the
invalid value (user id, config id), so that the displayed filter
reflects the actual data listed in the Database Configuration table.

Fixes the bug reported by atrol in issue #14559's bugnote 34648
Config report: preset the edit form to the current filter

The 'Username', 'Project Name' and 'Configuration Option' fields in the
'Set Configuration Option' form are now preset to the corresponding
value from the filter or defaulting to ALL_USERS, ALL_PROJECTS and blank
respectively if the filter is not defined or set to '[any]'.

This allows easier definition of related config, e.g. for a given
project or user.
Config report filter: added buttons to clear and reset default filter

This provides the user with a single-click way to

 - reset the filter to default settings
   (i.e. ALL_USERS, ALL_PROJECTS, [any] config).
 - clear the filter to display all configs
   (i.e. [any] user, [any] project, [any] config)

Issue #14559
Fix performance issue on adm_config_report.php

In systems with large numbers of config items in mantis_config_table, the
Configuration Report page can take a very long time to load.

This behavior is due to each of the 'Delete' buttons being printed with
its own form, each one having a security token. The performance
bottleneck is actually the serialize/unserialize calls executed while
storing/retrieving the token from the PHP session.

To avoid this problem, the print_button() and form_security_field()
functions have been modified to accept a security token as an optional
parameter. This allows the calling page to generate a single token,
which is shared by all buttons.

Furthermore, print_button() also allows the security token parameter to
be 'OFF', which prevents the function from displaying a security field.
This is useful for buttons not resulting in modifications (i.e. not
requiring CSRF protection).

Fixes #13680