Add sdk/metric/view structure to new_sdk/main

[MrAlias]

Blocked by #2799

• Build the unimplemented structure of the sdk/metric/view package.
• Ensure all implementation TODOs have an issue tracking them.

[MrAlias]

The current views package in the new_sdk/example branch has the following types:

type (
	View struct {
		cfg Config
	}

	Config struct {
		...
	}
)

I would propose we rename the package to view and just export a Config type. That way func WithViews(views ...view.Config) Option in the sdk/metric reads without a stutter. Additionally, if we then have New(...Option) Config in the view package the call would be WithViews(view.New(...), view.New(...) and this would match our existing configuration patterns.

[MrAlias]

I'm wondering if all this view configuration structure is needed. The view is ultimately only going to be passed to a MeterProvider as an option. Why not define it as a type directly in the sdk/metric package with exported fields for all configuration options and an associated NewView function that returns a View with all the defaults set?

[Aneurysm9]

We use functional options for this sort of configuration pretty much everywhere else. It would feel incongruous to not do so here.

[MrAlias]

Closed by #2838