feat(adi): v2 tags — compound / computed / FOR expressions on ADT, opt-in

[russimicro]

This one needs a decision from you, not just a review. It is opt-in and
defaults to off, so merging it changes nothing for anyone who does not ask
for it. The question is at the bottom, and "no" is a fine answer.

Closes #147. Closes #159.

What the format cannot do today

A .adi bag stores, per tag, a single field number. That is enough for
INDEX ON Field, and it is what SAP's format holds. It cannot express what an
xBase application actually indexes:

INDEX ON cClasi1+cClasi2+cClasi3+cClasi4+cClasi5+cCodigo  TAG ARTICLAS
INDEX ON UPPER(cNombre)                                   TAG NOMBRART
INDEX ON cCodigo  FOR nExistencia > 0                     TAG ORDER17

Our article table asks for 22 tags of those shapes. On today's format the
bag ends up holding one, so every DBSETORDER / column-click that asks for an
order that is not there falls back to a scan or to building the index on the
fly over 34,595 rows. #159 is the same limitation seen from the API side
(AdsCreateIndex61 with a compound expression -> 5063).

What v2 is

An OpenADS-proprietary layout for the per-tag header and the dense leaf:

• tag identity by name, plus the key expression and the FOR condition
  persisted, so both survive a reopen (the legacy header has nowhere to put them);
• dense leaf with front coding, so a compound key of 40+ bytes does not blow
  up the bag;
• a bulk build path for CREATE INDEX / REINDEX — inserting one key at a
  time is not viable on a large table;
• the key count of a conditional tag comes from the index, not from
  record_count().

It is not byte-compatible with SAP's .adi. That is the whole point of the
question below: a bag written by v2 is ours, not theirs.

How the switch behaves

OPENADS_ADI_V2, read at index-creation time.

• off (default) — AdsCreateIndex61 behaves exactly as it does on main:
  a bare field tag takes the legacy layout, and a compound / computed expression
  is rejected rather than written into a header that cannot describe it.
• on — character and expression keys take the v2 layout.

Reading auto-detects: a v2 bag is recognised by its own metadata, a legacy bag
is read as before, with the switch in either position.

Measured on real data

34,595-row ADT table, tags created from scratch:

tag	expression	build
plain	cCodigo	62 ms
compound	cClasi1+...+cClasi5+cCodigo	78 ms
computed	UPPER(cNombre)	125 ms
conditional	cCodigo FOR nExistencia > 0	47 ms (5,408 of 34,595 keys)

Opening the resulting 26 MB bag with 22 tags: 17.8 ms.

Known gap, stated up front: a numeric key does not take the bulk path yet
and builds in ~3 s. The ordering is correct; it is the build that is slow.

What it touches outside the ADI driver

One branch in AdsGetRecordCount: with an ADI order active the count comes from
the index walk (via count_live_recnos, the helper the CDX branch already uses)
instead of the table's physical record count. Without it a conditional tag
reports every row in the table rather than the subset it indexes. rddads
answers OrdKeyCount() through this entry point and TXBrowse asks for it
hundreds of times per open, so it must not walk the table per call.

One behaviour change you need to know about

With v2 on, AdiIndex::list_tags() returns the tag name the caller passed to
AdsCreateIndex61 (TCODIGO), not the indexed field name (CCODIGO) — the
legacy format could only report the latter because it stored nothing else. With
the switch off, nothing changes.

Tests

Full suite green with the switch off (1297 cases): that is the important
number, since off is the default. The two cases that exercise v2 turn it on for
their own duration and put it back afterwards.

New: abi_adi_native_estaelec_test (compound / computed / FOR tags, ordinals),
abi_adi_frontcoding_size_test (leaf density), abi_adi_estaelec_compound_test,
abi_adi_reindex_bench_test, abi_adi_dat_extension_path_test,
abi_adi_clear_multilevel_test.

The question

Any of these three works for us, we just need to know which:

(a) it goes in behind OPENADS_ADI_V2, off by default — as it stands in this
PR: nothing changes for existing users and we stop maintaining a parallel format;

(b) it goes in as the default for newly created bags, keeping the legacy
reader for existing ones;

(c) it does not go in, and we keep it in our fork.

(c) is a perfectly good answer. What we cannot do is keep guessing: #147 has
been open since 29 July with no reply. If the honest answer is "not this
format", saying so costs you nothing and saves us from syncing something you
intend to solve another way.