Allow EAP startup using IPv6 bind address and multicast address

The Main Problem: URLs
==================
The problem we have at the moment is that URLs are used in many places within the AS (for specifying RMI codebases, for describing the location of Remoting Connectors, etc) and these URLs are often specified in MBean configuration files using direct substitution of jboss.bind.address and port. For example, we may use direct substitution in an XML configuration file to specify an InvokerLocator:

<attribute name="InvokerLocator">
<![CDATA[socket:://${jboss.bind.address}:8084]]>
</attribute>

With substitution of an IPv4 address, we end up with the URL socket://192.168.0.100:8084, but with substitution of an IPv6 addressw, we end up with the URL
socket://3ffe:ffff:100:f101::2:8080.

There are two problems here. Firstly, socket://3ffe:ffff:100:f101::2:8080 is not a well-formed IPv6 URL, as according to the relevant RFC; it should be formatted as socket://[3ffe:ffff:100:f101::2]:8080. Secondly, once the IPv6 address and port have been concatenated, it is impossible to parse them back into their component parts. For the non-well-formed address
socket://3ffe:ffff:100:f101::2:8080 can be correctly interpreted as socket://[3ffe:ffff:100:f101::2:8080] (with no port specification) or socket://[3ffe:ffff:100:f101::2]:8080

If we start the AS using -b <IPv6 address> and -u <IPv6 mcast address>, many MBeans do not start correctly. Sometimes, in the case of the WebServices MBean, we have passed a non-well formed URL to java.rmi.server.codebase and parsing fails. In many cases, services which depend on Remoting do not obtain the correct server invoker as the URL passed to the InvokerLocator is incorrectly formed, parsing fails, and we end up using a localhost based URL. In short, the AS will not start up when using IPv6 addresses as above.

NOTE: There are secondary problems with JNDI lookups (Context.PROVIDER_URL does not parse correctly with IPv6 addresses) and HA-JNDI lookups (auto-discovery is also broken, as it needs to parse host:port combinations), but these are fixable if a well-formed URL is presented in the JDNI environment. See https://jira.jboss.org/jira/browse/JBPAPP-2941.

The Main Workaround: Enclose IPv6 addresses in brackets
===========================================
A workaround to this problem is to enclose IPv6 bind addresses in square brackets, starting up the AS like this:

./run.sh -b [<IPv6 address>] -u [<IPv6 mcast address>]

In this case, direct substitution of jboss.bind.address leads to correctly formed URLs, and most of the problems mentioned earlier are avoided, and the AS manages to boot. As it happens, we are lucky in that InetAddress.getByName() is smart enough to trim the enclosing square brackets from the IPv6 address string and converts the address successfully. This feature is used by JGroups, which does not work with URLs but rather InetAddress strings.

There are still problems with JNDI when using this workaround, but small fixes to org.jnp.interfaces.NamingContext.java and HADetatechedInvoker address these problems.

Staring the AS with a hostname which resolves to an IPv6 address also seems to work OK.

Where We Are At The Moment:
=======================
With square brackets and fixes to NamingContext, i've managed to get the first part of the AS 4.3 testsuite to pass (up to the clustering tests, for which i'm still creating fixes for auto-discovery to get the testsuite to work).

However, the problem remains that the square brackets are required in order to work around these issues, and it really is a workaround to two problems: URLs are being formed in XML descriptors without taking IP address version into account and (ii) IP address + port combinations are being parsed by assuming we can use the colon as a token separator.