ddtrace/tracer: add span.SetTags method

[jirikuncar]

Add SetTags method to help with setting multiple tags at once.

1. It avoids locking per key for spans with many tags.
2. This method is particularly useful in combination with contrib/testing: trace test executions with detected CI information #770 which extract multiple tags from CI providers at once.
3. Brings a feature parity with dd-trace-py, dd-trace-rb,

[gbbr]

Please consider opening an issue to discuss adding new features before writing code, as per our contribution guidelines.

That being said, I don't think we want another SetTag flavour. Having too many ways to do things was the original reason for refactoring the original Go tracer. This library is meant to offer a toolbox to allow you to build your own features. The current library already supports setting tags, and one can easily create their own helper function shall they need to, using a for loop.

[knusbaum]

Locking when there's no contention is very efficient. On my machine it takes ~ 20 ns to Lock and Unlock a span:

$ go test -run XXX -bench BenchmarkLockSpan -benchmem -benchtime 20s
BenchmarkLockSpan-8   	1000000000	        21.8 ns/op	       0 B/op	       0 allocs/op

When using SetTags(tagmap) we would then expect to save ~len(tagmap) * 20 ns.
To confirm, I ran a couple quick benchmarks (source) and indeed I see a little less than that, both with a SetTags(map[string]string) and a more generic SetTags(map[string]interface{}).

They show a ~1000-2000 ns improvement in speed when setting 100 tags by avoiding the lock. We would have to set thousands of tags to see a real impact. I think this is not a big enough improvement or common enough use case to justify adding a method to the public Span interface, which we would have to do.

BenchmarkSetTagsMetaMap-8             	 2252941	     17265 ns/op	   29787 B/op	      21 allocs/op
BenchmarkSetTagsGenericMap-8          	 2049588	     17252 ns/op	   29791 B/op	      21 allocs/op
BenchmarkSetTagsIterateGenericMap-8   	 1958858	     18237 ns/op	   29797 B/op	      21 allocs/op

Please share if you've seen lock-related performance issues, or if there's some other reason you want to avoid the lock.

[jirikuncar]

@knusbaum ok, so I will add the same code as a private method when implementing #772.

[knusbaum]

I'm going to close this for now.