Improve AnyP::Uri::port_ and related port storage types (#1255)

Improve AnyP::Uri::port_ and related port storage types (#1255)

The old "unsigned short" type is used for various things all over the
code and cannot distinguish a parsed port zero from an absent port. In
theory, it could also hold values exceeding 65535, getting out of sync
with various (poorly duplicated) maximum port value checks.

No significant runtime changes are expected, but some transactions with
unknown request URI ports may now be reported correctly, showing "-"
instead of "0" for the missing port number. In some very special/rare
on_unsupported_protocol cases, Squid might no longer attempt to tunnel
non-HTTP requests to a zero port. Such attempts were failing anyway.

This change leaves many "unsigned short" port use cases untouched. Most
of them should be converted, but most (if not all) of those conversions
should be done in dedicated projects. Here are a few TODO highlights:

* ACLIntRange: Stores integers, is usable for integers, but assumes it
  is being configured with port numbers. We probably should enhance that
  class to handle "all" integers instead of expanding/deepening that
  rather limiting "input is just port numbers" assumption.

* CachePeer and internalRemoteUri(): Likely runtime changes related to
  squid.conf validity.

* Ftp::Server::listenForDataConnection() and friends: Triggers a few
  changes with runtime effects related to comm_local_port() failures.

* Ip::Address, Snmp::Session, fde: Too many low-level changes, some of
  which would be difficult to test.

* Config.Port.icp: Possible runtime changes related to squid.conf and
  command-line arguments validity.

Also used "%hu" instead of "%u" or "%d" to printf() ports. These changes
arguably improve code and might make some pedantic compiler happier, but
they do not fix any "real" bugs because variadic printf() arguments are
automatically promoted from short to int and, hence, printf()
implementations never get and never expect shorts.