Provide explicit override rules for AggregationTemporality across Exporters, Views and defaults.

[jsuereth]

As a follow on to #2013 (and a discovery in open-telemetry/opentelemetry-java#3762), we should explicitly clarify the override rules of AggregationTemporality in the SDK.

Specifically:

1. If a View is configured with explicit AggregationTemporality and an Exporter does not support it, what should happen?
2. If a View is configured with explicit AggregationTemporality and an Exporter does not prefer it, what should happen?
3. If a View is not configured with explicit AggregationTemporality and an Exporter does have a preference, what should happen?
4. If a View is not configured with explicit AggregationTemporality and an Exporter does not have a preference, but supports either, which should be chosen?
5. Should we allow CompositeExporter as a concept? Would this take the intersection of all allowed temporalitites?

Proposal

For reference, the Java implementation defines this in the following test.

• View configuration takes precedence (even being chosen over supported temporality of exporters).
• Exporter preferred temporality takes next precedence
• Next, CUMULATIVE is chosen if nothing else has decided.
• Lastly, DELTA wins if it's the only option left.

cc @reyang