[Vote] apr-iconv-1.1.0

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Since apr-iconv-1.0.1 is only available as .gz, and our DOA .Z archives,
I'd rerolled/resigned 1.0.1 tar.gz, tar.bz2, and win32 zip, and dropped
them up on apr.apache.org/dev/dist/.  This seems to be a minimum effort
required, if we continue to call 1.0.1 our 'stable' version.  When I
pulled this against a buildconf --with-apr=1.2.2, it screamed that arg
4 of APR_FIND_APR was missing, and that it would search for APR 0 or 1.
Then I got thinking...

We have the ambiguity of side-by-side apr-iconv 0.9 and 1.x loadable
charset modules, which use different formats.  There were objections
to immediately dropping support for APR_ICONV_PATH envvar, so if the
new APR_ICONV1_PATH is set, we will ignore any APR_ICONV_PATH value.
with this change, they can coexist side-by-side.  At the same time,
if a module packager hasn't yet updated their run-scripts to use
APR_ICONV1_PATH, and there's only apr-iconv-1.x in use, the user will
experience no problems.

We've discussed additional cool ideas;

  * resolve the apriconv-1.so module path, and follow the parallel subdir
    apriconv-1/*.so for loadable modules (to distinguish side-by-side
    installs of 'generic' iconv/ from apriconv-1/.)  Needs a new apr core
    function apr_dso_filepath_get() or some such, which won't happen
    until APR-1.3.

  * tag apr-1 loadable .so charset modules to distinguish them from apr-0
    loadable .so charset modules.  Introduces binary breakage, I believe,
    which couldn't happen without going to apr-iconv-2.x.

We also want to extract APR m4 build templates, and we then needed to
update the buildconf to properly invoke APR_FIND_APR(,,,[1]) so we don't
accedently pick up APR-0.

Thus, it's a whole new package, apr-iconv-1.1.0, for your consideration.
I've dropped them on apr.apache.org/dev/dist/ for review and votes, 
please vote on this reroll so we can distribute corresponding .tar.gz /
.tar.bz2 / .zip files for all now-current packages.

Bill