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