filter api: always treat FILTER_PROPERTY_MATCH_TYPE as an int value

Based on @dregad's comments, this follows up on @dhx's fix.

Fixes #15373: XSS vulnerability 
Fix #15384: summary.php XSS vulnerability in MantisBT 1.2.12 only

Roland Becker (MantisBT Developer) discovered a XSS vulnerability
introduced in MantisBT 1.2.12 with the display of category/project names
on the summary.php page.

A malicious MantisBT user holding privileged manager/administrator
permissions could create a category or project name that contains
JavaScript code. Any user visiting summary.php from that point on may
then be exposed to having the malicious JavaScript execute within their
browser environment.

The severity of this issue is limited by the need to hold privileged
manager/administrator permissions in order to modify category and
project names. However -- there are many use cases where MantisBT
installations can have hundreds of sub-projects, each managed by
different people/parties that can not or should not be fully trusted.

Refer to previous commits 3ca8a164 and 6ec3f693 to trace back the origin
of this vulnerability.
Revert "filter api: always treat FILTER_PROPERTY_MATCH_TYPE as an int value"

This reverts commit 610da6ecda08239187bc12bf9bf35ba4d27f1920.

This fix reopens the reported vulnerability therefore it is reverted.
Update match_type parameter to be XSS-safe by itself

Use of gpc_get_int() instead of gpc_get_string() prevents malicious
users from passing arbitrary strings as parameter.

Fixes #15388
Display of match_type filter property for unknown types

Prior to this, if for any reason the filter's match type property was
not one of the predefined types (i.e. 'any' or 'all'), the code would
default to 'all', but display a blank string on the filter page. This is
confusing to users, so the display now matches the filter's actual
behavior.

Fixes #15389