TestConnUnicastSocketOptions doesn't work on nacl, plan9, or windows,
but the t.Skip at the top was missing the GOOS == "windows" check. (It
was present in the ipv6 version of the test)

The test than proceeded to try to run and set up a connection pair
for testing. Here's what was happening.

Goroutines are M (main, the client) and S (server, doing the Accept):

   M: net.Listen("tcp4", "127.0.0.1:0"), succeeds.
   M: defer ln.Close() enqueued.
   M: go acceptor() (start "S" (server) goroutine)
   M: net.Dial("tcp4", ln.Addr().String()), succeeds.
      Notably, it's connected to the kernel's TCP stack at this point.
      The userspace Accept hasn't run. Go's listen backlog is
      syscall.SOMAXCONN on Windows (which is fine).
   M: testUnicastSocketOptions:
      - finds that it's GOOS == "windows",
      - calls t.Skipf, which calls runtime.Goexit, runs deferred goroutines
   M: ln.Close() (previously deferred runs)
   M: test completes

Then:

   S: server goroutine finally schedules
   S: c, err := ln.Accept(), gets an error (because it's closed)
      if err != nil {
           t.Error(err)   // setting an error after test is done; bogus

So, fix it both ways: skip the test earlier on "windows", and simplify
the server goroutine and move the failing into the main goroutine.
Also skip other tests earlier on Windows that will also t.Skip. They
don't have goroutines, but might as well skip earlier.

Fixes golang/go#17655

Change-Id: I5d910d70943be37b2b4b56542ee98e42fc3acd71
Reviewed-on: https://go-review.googlesource.com/34021
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>