Implement the sdk/metric/number package

[MadVikingGod]

Blocked by #2799

• Implement the sdk/metric/number package
• Ensure that the package is tested
• Document the package in the godocs
• Ensure all implementation TODOs have an issue tracking them.

[MrAlias]

Should the number and sdkinstrument package be combined into a single instrument package that instead calls the Number type Value?

[MrAlias]

I think we can avoid exporting a number package entirely. I added the following to the the sdk/metric/internal package:

// Atomic provides atomic access to a generic value type.
type Atomic[N int64 | float64] interface {
	// Store value atomically.
	Store(value N)

	// Add value atomically.
	Add(value N)

	// Load returns the stored value.
	Load() N

	// Clone creates an independent copy of the current value.
	Clone() Atomic[N]
}

type Int64 struct {
	value *int64
}

var _ Atomic[int64] = Int64{}

func NewInt64(v int64) Int64 {
	return Int64{value: &v}
}

func (v Int64) Store(value int64) { atomic.StoreInt64(v.value, value) }
func (v Int64) Add(value int64)   { atomic.AddInt64(v.value, value) }
func (v Int64) Load() int64       { return atomic.LoadInt64(v.value) }
func (v Int64) Clone() Atomic[int64] {
	return NewInt64(v.Load())
}

type Float64 struct {
	value *uint64
}

var _ Atomic[float64] = Float64{}

func NewFloat64(v float64) Float64 {
	u := math.Float64bits(v)
	return Float64{value: &u}
}

func (v Float64) Store(value float64) {
	atomic.StoreUint64(v.value, math.Float64bits(value))
}

func (v Float64) Add(value float64) {
	for {
		old := atomic.LoadUint64(v.value)
		sum := math.Float64bits(math.Float64frombits(old) + value)
		if atomic.CompareAndSwapUint64(v.value, old, sum) {
			return
		}
	}
}

func (v Float64) Load() float64 {
	return math.Float64frombits(atomic.LoadUint64(v.value))
}

func (v Float64) Clone() Atomic[float64] {
	return NewFloat64(v.Load())
}

This was then used by the aggregators to atomically aggregate values in the proof-of-concept I made from #2954.

I think avoiding exposing this implementation detail is advantageous. It will provide flexibility in the future, stops us from tracking a number type everywhere, and reduces the amount of exported API we will need to maintain in the future.

[MrAlias]

It seems like this package may be avoidable based on the current direction the SDK (specifically the aggregations) is going.

Closing to remove possibly stale work. We can reopen this if it is deemed necessary in the future.