Ensure exported interfaces have named method parameters

[matej-g]

In line with the suggestion in #1135 (review), this PR intends to ensure exported interfaces have named method parameters by:

• going over existing exported interfaces and naming method parameters where missing
• updating the Style Guide to ensure this style choice is respected in future code changes

The aim of this change is to improve documentation and to bring about consistency in this matter.

Resolves #1138

[codecov]

Codecov Report

Merging #1172 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master   #1172   +/-   ##
======================================
  Coverage    77.9%   77.9%           
======================================
  Files         135     135           
  Lines        7192    7192           
======================================
  Hits         5603    5603           
  Misses       1346    1346           
  Partials      243     243           

Impacted Files	Coverage Δ
api/metric/metrictest/async.go	78.1% <ø> (ø)
api/metric/sdkapi.go	100.0% <ø> (ø)
api/propagation/propagation.go	100.0% <ø> (ø)
api/trace/tracetest/config.go	91.8% <ø> (ø)
label/encoder.go	88.5% <ø> (ø)
sdk/export/metric/metric.go	97.6% <ø> (ø)
sdk/metric/controller/time/time.go	75.0% <ø> (ø)
sdk/metric/processor/reducer/reducer.go	100.0% <ø> (ø)
sdk/trace/sampling.go	100.0% <ø> (ø)
sdk/resource/auto.go	0.0% <0.0%> (ø)

[XSAM]

Should we update these *Option interfaces too? These interfaces also exported.

e.g.

opentelemetry-go/api/metric/config.go

Lines 33 to 38 in 77de199

	// InstrumentOption is an interface for applying instrument options.
	type InstrumentOption interface {
	// ApplyMeter is used to set a InstrumentOption value of a
	// InstrumentConfig.
	ApplyInstrument(*InstrumentConfig)
	}

[matej-g]

Should we update these *Option interfaces too? These interfaces also exported.

I was considering that as well, but in the end decided not to, as it seemed to me that these interfaces are part of the "standardized" style (https://github.com/open-telemetry/opentelemetry-go/blob/master/CONTRIBUTING.md#option) and therefore should be clear enough on their own. But I'm not opposed to including it there as well if that's the preference here.

[Aneurysm9]

Should we update these *Option interfaces too? These interfaces also exported.

I was considering that as well, but in the end decided not to, as it seemed to me that these interfaces are part of the "standardized" style (https://github.com/open-telemetry/opentelemetry-go/blob/master/CONTRIBUTING.md#option) and therefore should be clear enough on their own. But I'm not opposed to including it there as well if that's the preference here.

I'm on the fence about this. I think that generally the Option interfaces will be dealing with internal types and won't be used by end-users, but I can also see the argument that they should be documented for consistency.

@rakyll do you have thoughts on this?

[MrAlias]

Should we update these *Option interfaces too? These interfaces also exported.

I don't think this should block this PR but indeed is a good question. I'm as well on the fence. I think the repeated pattern and having this pattern pretty well documented in our style guide makes this clear.