Fix missing spans in gorillamux instrumentation

[JamieDanielson]

Which problem is this PR solving?

• closes empty spans are generated by auto-instrumentation #81

Short description of the changes

The first commit updates the expected output of a trace for nethttp instrumentation, removing the empty second span. The next set of commits adjusts the http server instrumentation, ultimately just adjusting one of the changes in #34 that used an array of two function names for ServeHttp and keeping only the newer "net/http.HandlerFunc.ServeHTTP".

• Another commit updates the expected output of a trace for gorillamux instrumentation, updating the empty gorilla/mux span to include the http info.
• And finally, the gorillamux instrumentation was updated to match the nethttp/server changes made in Fix net/http instrumentation for register-based ABI #34
• Updated per PR feedback: Method Length has been set to 7 instead of 6 to include items like OPTIONS. This has been adjusted for gin-gonic and nethttp server instrumentation as well.

I'm not really sure what the trace for gorillamux should look like; the same info exists for two spans, but one is named for net/http and is for gorillamux. This doesn't address that. The trace was already emitting two spans, with the gorillamux span being empty - and this PR populates the gorillamux span.

Note: This has been updated as several of the changes made were ported into #82 . Since then, the gorilla/mux spans were empty. This PR still has the effect of populating the gorilla/mux spans.

[TylerHelmuth]

Exciting!

[JamieDanielson]

Just a note, I'd been holding off on any further changes here to help get #92 across the line first with minimal merge conflicts there. Some of these changes are in #82 now so I'll wait on that one as well and then there may be nothing left on this one. If anyone thinks this approach should change let me know.

[JamieDanielson]

This is ready for re-review. For reference, running make fixture-gorillamux without replacing the trace/span IDs with "xxxxx" results in different trace/span IDs which is expected, so it's not a true duplicate of the net/http span. The extra net/http span is worth looking at but may be best addressed in a separate PR, and will be fixed if we implement consolidated http instrumentation referenced in #101

          "scope": {
            "name": "github.com/gorilla/mux"
          },
...
              "name": "/users/foo",
              "parentSpanId": "",
              "spanId": "a965bd2e4dec00c4",
              "status": {},
              "traceId": "5a5dc1cc0de7798f1d349248975d35db"
...
          "scope": {
            "name": "net/http"
          },
...
              "name": "/users/foo",
              "parentSpanId": "",
              "spanId": "ad51aa0cebcf8d6b",
              "status": {},
              "traceId": "a4a1761ce09da7ca6cc54d7d4d25611b"