v1.28

Define Neon here: procrule's link has no other definition

procrule.c declared

    extern int Neon;

and nothing in procrule's link defines it. The only definition is in mdxfind.c,
which is a different program. Every non-ARM build compiled the reference out,
so it linked everywhere and the gap stayed invisible until the release began
passing a real ARM value rather than a bare -DARM.

AArch64 was safe too: get32_init selects get32_neon64 first and get32_neon32
is never compiled there. It is 32-bit ARM at ARM >= 7 that needs the symbol,
and it failed with an undefined reference to Neon at link.

Defining it and leaving it zero would not be enough. Neon gates the NEON hex
decoder at runtime, so a bare definition links and then always picks
get32_scalar -- a silent no-op of exactly the kind this file was corrected for
one revision ago. get32 is a lazy-init function pointer, so the probe sits in
get32_init immediately before the choice it feeds: no change to main, and it
cannot run too late.

The probe reads Features from /proc/cpuinfo and looks for neon or simd, the
same test mdxfind makes. These are static binaries run on whatever board turns
out to be present, so asking the kernel beats trusting the -march they were
built with. A missing or unreadable /proc/cpuinfo answers no, which costs speed
and not correctness -- get32_scalar decodes the same bytes.

Verified on arm-linux-gnueabihf: armv6, armv7 and armv8 32-bit all compile and
link, where armv7 and armv8 previously failed at link. armv7 and armv8 grow
from 228K to 584K, which is the NEON path now actually being built. Intel is
unchanged and the 1.27 known-answer tests still pass.