Add named pipe support for windows

[randomanderson]

This PR adds named pipe support for windows machines. Named pipes are similar to unix domain sockets. This PR supports submitting metrics to Datadog in Azure App Services (https://github.com/DataDog/datadog-aas-extension).

The main changes are:

• Abstracting DatagramChannel into the ClientChannel interface
• Adding a ClientChannel implementation for named pipes
• Adding configuration support in the builder
• Subclassing DummyStatsD server for testing of the 3 transport types

Unfortunately, only existing named pipes can be written to in pure Java. In order to create named pipes for testing, JNA is used.

[vickenty]

Looks mostly good. Left a few comments inline, please let me know what you think.

[randomanderson]

@vickenty Did you want to rereview or should I just merge this PR with the fixes?

[vickenty]

@randomanderson Sorry for the delay, I will take another look. Meanwhile, we would like to make sure configuration options are the same between libraries for different languages. Windows pipes are not universally supported by all libraries we support, but where it is available, we'd like the configuration to be the same (same env vars / methods). Can you please check if we're aligned with https://github.com/DataDog/datadog-go for example?

[randomanderson]

@vickenty Windows pipes are only implemented in .NET and the dogstatsd server. They both use DD_DOGSTATSD_PIPE_NAME which is what I used here

[vickenty]

There are some warnings in the CI, would you mind taking a look and fixing if any are new?

Do you think it might be useful to throw an error if named pipe is requested on a non-windows OS?

[randomanderson]

@vickenty There were a few javadoc warnings that I fixed. The rest of the warnings were preexisting (one about the deploy plugin missing a version and one about the EnvironmentVariables test fixture)

There's no error for Unix Domain Sockets on Windows so I don't think there needs to be one for named pipes. If the named pipe does not exist, an IOException is thrown.

[vickenty]

LGTM, except one small nit.

[vickenty]

Would this work?

Suggested change

	return new DatagramClientChannel(DatagramChannel.open(), address);
	return new DatagramClientChannel(address);

And then DatagramChannel import can be removed, and maybe 2-argument constructor too (other client channel impls don't have one, so I guess we don't need one there too).

[randomanderson]

@vickenty I made that small change. I left the 2-arg constructor because UnixDatagramClientChannel uses it.