MINOR: filters: Support the global side in filter_place_class()

MINOR: filters: Support the global side in filter_place_class()

The filter classes are anchored in three independent orders: the global one,
which drives the side-independent operations (configuration checks,
initialization and destruction), and the request and response ones, which
drive the stream evaluation order. Until now the global order could only
follow the class registration order, filter_place_class() only accepted
FLT_SIDE_REQ and FLT_SIDE_RES, and the per-side anchors were two anonymous
inline structs, which made the global order impossible to refine and the
placement code side-specific.

The three orders now share a common anchor type, struct filter_class_side,
holding the before/after constraint lists, the link in the order list and a
placed flag. The class registry (filter_class.list) stays a flat list in
registration order, used by filter_find_class() and "haproxy -vv", while the
global order is a new distinct list, global_filter_classes, rooted in
filter_class.global.list. As for the channel sides, the global order is a
placement tree: a registered class is appended at the end of it, and
filter_place_class() re-parents it relative to another class.

filter_place_class() now accepts FLT_SIDE_GLOBAL. Any registered class may be
used as a reference on that side, since the global order contains all of them,
whereas a channel side still requires the reference class to be placed on that
same side. Moving a class in the global order does not change its request or
response positions, and the three placements remain independent. Two new
errors are reported: a class cannot be placed relative to itself, and a class
cannot be placed twice on the same side.

filter_register_class_full() places the class on the global side as well, so
the helper keeps placing the class symmetrically in every order. Its error
path now detaches the class from all its orders, through the new
flt_unplace_class() helper, instead of only unlinking it from the registry.

The default order of the internal classes does not change: the same classes
are appended to the global order, which is required for the global class
references to be created at proxy initialization. This only makes the global
order refinable by modules and lifts the last asymmetry between the three
orders.

The documentation is updated accordingly, in both the configuration manual
and the internals guide, together with the example in the comment of
filter_init_classes().