RE: Compilation issues for HASH_STATISTICS and HASH_DEBUG options

Dear David,

> FWIW, I've no personal need to keep HASH_DEBUG, but if someone does,
> then let's keep it. Maybe we can make it use elog(DEBUG<N>) rather
> than fprintf and at least build with it in some BF member so we notice
> sooner if someone breaks it again. (I've not checked if there's a good
> reason why we can't use elog(). Perhaps something dynahash related
> happens to early in backend startup...)

Just in case: actually, even if the HASH_DEBUG part is fixed on PG17, it could
not pass some tests. One example is initdb test [1].
ISTM, command_like() assumed that there are no outputs in stderr but this option
does. This meant no BF animals cannot set this option as-is.
After I changed them to elog(DEBUG1) (and set debug1 as default) I ran tests
under src/test, and they could pass.

[1]:
```
[13:55:38.836](0.001s) not ok 29 - options --locale-provider=icu --locale=und --lc-*=C: no stderr
[13:55:38.836](0.000s)
[13:55:38.836](0.000s) # Failed test 'options --locale-provider=icu --locale=und --lc-*=C: no stderr'
# at t/001_initdb.pl line 131.
[13:55:38.837](0.001s) # got: 'init_htab:
# TABLE POINTER 0x180ee70
# DIRECTORY SIZE 256
# SEGMENT SIZE 256
# SEGMENT SHIFT 8
# MAX BUCKET 3
# HIGH MASK 7
# LOW MASK 3
# NSEGS 1
...
```

Best regards,
Hayato Kuroda
FUJITSU LIMITED