core, mod_proxy: Send the supported methods in Allow for a denied TRACE.

[arturobernalg]

With TraceEnable off the 405 for a TRACE request carried an empty Allow field, although GET, HEAD and OPTIONS work. The 405 is sent before any handler has declared the methods of the resource, so list the ones httpd answers for any resource. BZ 65357.

---

• This PR does not report or address a security vulnerability
  (see SECURITY.md and
  https://www.apache.org/security/#reporting-a-vulnerability).
• Code follows the httpd style guide.
• New log messages (level debug or higher) use an empty APLOGNO() tag;
  numbers are assigned by a committer at merge time (see docs/log-message-tags/README).
• If the change is user-visible, a changes-entries/*.txt file is included,
  following the template in README.CHANGES (not needed otherwise).
• Test cases based on pyhttpd are included where appropriate, in the
  test/modules/xxx directory matching the modules/xxx module source,
  or test/modules/core for core server changes. On Unix, verify these
  pass locally with e.g. make check-pytest PYTEST_DIRS=test/modules/xxx.

[arturobernalg]

Closing this approach.

The fixed Allow value is not correct for arbitrary resources. For example, a proxied resource that supports only POST receives:

Allow: HEAD,GET,OPTIONS

for a TRACE rejected by TraceEnable off, although none of those methods are supported by the target.

At the point TRACE is rejected, httpd has no generic mechanism to determine the target handler/backend's supported methods, so an exact 405 response cannot be constructed without broader handler capability support.

A policy-based status such as 403 might avoid that problem, but changing the long-standing TraceEnable off status from 405 would be a separate compatibility/design decision.