In the bug relationships section in view.php, the target bug's status
was incorrectly displayed as "@x@" (where X is the status_enum id) if
the following conditions were true:
 - the target bug is in a different project
 - it is a custom status

This commit fixes the behavior, and displays the corresponding enum
element's language string.

2 new parameters have been added to function get_enum_element(): user
and project id (defaulted to null to preserve existing behavior). These
parameters are passed on to config_get() call, allowing to specify the
context for retrieving the enum element.

The call to get_enum_element() in function relationship_get_details()
has been altered to specify the target bug's project id.

Fixes #11323

Resolves additional display issues of custom status cross-project, similar
to what was fixed in 324dbb4681255b7a1fa4cc309ab8742f028dbf43. These
can occur when "All Projects" is selected and one or more projects have
custom statuses not defined globally, in the following pages:

 - View Issues
 - Change Log
 - Roadmap
 - Sponsorship

Affects #11323

 - fix whitespace errors
 - align to coding guidelines
 - moved variable initialization out of for loop

When a custom status is defined in a different project, its custom
color was not used (displayed white) in the following cases

- view issue details page, relationship
- View Issues
- My View
- Sponsorship
- Bug group action list

Fixes #13682

When a custom resolution is defined in a different project, its code
was displayed as @x@ instead of the corresponding string in the
resolution column, as well as when hovering over the status in the view
issues page.

Fixes #13707

When a custom severity is defined in a different project, its code
was displayed as @x@ instead of the corresponding string in the
severity column on the View Issues page.

The same problem applied to custom priorities

Fixes #13718

Fixes #13728

The CSV and Excel exports, as well as printing a report to Word now
properly handle custom enums when dealing with bugs from different
projects.

Fixes #13728

Copy/paste error introduced in 735506c

Affects #11323

Conflicts:
	excel_xml_export.php

Bug introduced by commit a786f9b.

Due to the use of number_format() function with default parameters, PHP
outputs the sponsorship amount formatted with ',' as a thousands
separator, which also happens to be MantisBT's default csv separator.
Since the fields are not escaped, this causes an extra column to be
generated.

Call to number_format() was removed, as it makes more sense to output
raw data in csv exports.

Fixes #13958

When exporting issues in Excel format a fatal error is thrown if the
export includes sponsorship totals. This is due to a missing
excel_format_sponsorship_total() function.

Fixes #13959

When private_bug_threshold is defined as an array instead of a single
access level, e.g. array(0=>40, 1=>70, 2=>90) to prevent developers
from seeing private bugs while granting that privilege to updaters,
access_has_bug_level() incorrectly returned true.

The consequence is that unwanted access to Private bugs was granted to
users who are allowed to view them, e.g. allowing them to delete or
perform other restricted actions.

Fixes #10124