Remove a false performance claim in addRowMultiple, and the dead macros behind it

[d-torrance]

The comment on the entries local in DenseRow::addRowMultiple claimed that
indexing mEntries directly instead would cost 14% of the whole matrix
reduction. That was measured on MSVC 2012 in 2013 and never since; its own
author wrote "That does not make sense to me, but it is a fact none-the-less."

It is not a fact on any compiler in use. Measured with the loop built both ways
and timed in interleaved runs against hyclic8-101-trimmed, yang1 and
hilbertkunz1:

• GCC 11.4 -O2, x86-64 emits different code with and without the local,
  and times the two within −0.9% to +1.4% — inside the run-to-run noise on all
  three inputs.
• clang 21, arm64 emits byte-identical object files either way, so there is
  nothing there to time at all.

MSVC cannot build this code regardless: stdinc.h has required C++17 since
PR #60, and MSVC 2012 does not do complete C++11. There is no compiler left for
which the claim could hold.

Removing the local leaves MATHICGB_RESTRICT with no users, and auditing its
neighbours in the same three compiler blocks found five more unused macros —
four of which have never been syntactically valid on GCC or clang
(__attribute__(x) where the syntax needs __attribute__((x))), plus one with
its while(0) inside the do block instead of closing it. The first use of any
of them would be a build failure. They have been that way since 2013 and nothing
noticed, because nothing uses them.

Commits

Each builds standalone and passes the full suite, so the series is bisectable.

1. 0190b09 — drop the restrict local and the assert that only checked
   vector::data() points where operator[] does
2. 6084a28 — remove MATHICGB_RESTRICT, now unused
3. 555dec3 — remove the five dead macros

On the API surface

stdinc.h is installed, so removing public macros is nominally an API removal,
with no ABI effect. Macaulay2 is the only known consumer and uses none of them:
grepping its tree for all six names returns nothing outside the mathicgb
submodule, and the only MATHICGB_* identifiers it references anywhere are
MATHICGB_LIBRARIES, MATHICGB_INCLUDE_DIR, MATHICGB_FOUND,
MATHICGB_VERSION_STRING, MATHICGB_DEBUG and MATHICGB_NO_TBB — things it
sets or probes for, not attributes it consumes. It also cannot reach these
definitions: it includes only mathicgb.h and mathicgb/mtbb.hpp, neither of
which includes stdinc.h.

Deliberately left alone

MATHICGB_ASSUME and MATHICGB_CONCATENATE also have no uses outside
stdinc.h, and both are load-bearing. MATHICGB_ASSUME is the non-debug
definition of MATHICGB_ASSERT, so removing it would break all 898 assertions
in release builds. MATHICGB_CONCATENATE backs
MATHICGB_CONCATENATE_AFTER_EXPANSION, which MATHICGB_UNIQUE needs. The
asymmetry in commit 3 is intentional: the macro whose comment begins "As
MATHICGB_ASSUME, but…" goes while MATHICGB_ASSUME itself stays.

The manual unrolling below the removed comment is a separate question and is
untouched. It was measured in the same pass and does earn its keep — replacing
it with a plain loop costs 8–12% on hyclic8-101-trimmed, though nothing on
yang1.

Verification

246/246 tests pass at each of the three commits. hyclic8-101-trimmed.gb is
byte-identical to before. The build with the local dropped times at −0.1%
against the build with it, sd 0.6–1.0% over 15 interleaved reps.

🤖 Generated with Claude Code