Add local/global scope modifiers for the db-info performance counters

[dyemanov]

There are two goals for this change:

1. Fix ISQL's SET STAT; to report local (current connection) page counters instead of global (per database) counters, as it makes performance analysis hardly possible under concurrent load in SuperServer. There will be a separate PR for that.
2. Allow collection of database-wise performance counters using only Attachment::getInfo(), without any MON$ table access.

New scope tags are allowed to be intermixed inside a single info buffer, every scope tag affects only counters requested after it. Thus it's possible to collect e.g. per-database page counters and per-attachment record counters using a single API call, if this would be ever required. Scope tags are returned "as is" inside the output buffer (for consistency).

If scope tags are missing, the legacy behaviour (per-database page and memory counters, per-attachment record counters) is preserved for backward compatibility.

[dyemanov]

Honestly, I'm not sure global vs local memory usage counters have much practical usage, but it's supported in this PR just in case anyone finds it useful.

[aafemt]

AFAICS only 6 counters are affected by flags. IMHO, it would be more clear to create 6 new info items instead.

[dyemanov]

AFAICS only 6 counters are affected by flags. IMHO, it would be more clear to create 6 new info items instead.

4 page counters, 2 memory counters and 8 record counters are affected. And we may have more in the future.

[hvlad]

I prefer, but not insist, to see
fb_info_counts_scope_attachment, fb_info_counts_scope_database
instead of
fb_info_counts_scope_local, fb_info_counts_scope_global

[AlexPeshkoff]

I prefer, but not insist, to see fb_info_counts_scope_attachment, fb_info_counts_scope_database instead of fb_info_counts_scope_local, fb_info_counts_scope_global

On my mind that should better be fb_info_counts_scope_private and fb_info_counts_scope_shared (typical for OS names), but I also do not insist.