Rename getAllHeaders where HttpMessage has already moved to its 5.x package - #176

UpgradeApacheHttpClient_5_DeprecatedMethods renames getAllHeaders() to getHeaders() on org.apache.http.HttpMessage, but it runs after UpgradeApacheHttpClient_5_ClassMapping. In a file that uses types of the org.apache.http package itself (HttpResponse, Header, …), the org.apache.http → org.apache.hc.core5.http package change has by then also moved the method's declaring type, so the pattern no longer matches and the call keeps a name HttpClient 5 does not have:

// before
HttpResponse httpResponse = ...;
Header[] allHeaders = httpResponse.getAllHeaders();
// after the migration today
Header[] allHeaders = httpResponse.getAllHeaders();   // cannot find symbol: method getAllHeaders(), location: ClassicHttpResponse
// after this change
Header[] allHeaders = httpResponse.getHeaders();

The existing test passed because its file only imports org.apache.http.client.methods.CloseableHttpResponse, so the declaring type kept its 4.x name. This matches both names, and overrides, so calls on requests such as HttpGet, where the method is declared on AbstractHttpMessage, are renamed too. The new test fails without the YAML change.

This surfaced while validating UpgradeApacheHttpClient_5 over the 1,346 open source repositories it changes in Moderne, in a 51-repository sample compiled before and after the migration: perwendel/spark, aliyun/aliyun-dataworks-dataservice-java-sdk, onap/archive-mso-libs, king-zyd/core and Unidata/netcdf-java. Rerunning the migration with this change and recompiling, the error is gone from all but Unidata/netcdf-java, where a call on an HttpRequestBase field remained; the same shape is renamed in a unit test, so something differs in that repository's model that I have not yet found.