API/feature parity considerations with closely-related xarray accessors

[jthielen]

The issues brought up in #2359 with unit arrays in xarray ops, as well as the non-idempotency in including units via multiplication, made me realize that pint-xarray's approach of having a units argument on quantify could handle this better. While I think we could adopt this particular change without any API break concerns, it does bring up an interesting set of broader questions in relation to the accessors of pint-xarray and cf-xarray:

• how much do we adopt new features/enhancements of these packages that go beyond what they replicated from MetPy?
• what do we do when APIs diverge between near-identical functionality? (document carefully? change API?)
• at any point should we drop .metpy accessor methods in favor of these other packages? or keep them in the .metpy namespace but simply wrap/encapsulate the other accessor's method?

[jthielen]

To summarize discussion from today's telecon: our goals here should be

• bring useful features developed in these other accessors into MetPy as they seem useful
• add aliases where APIs differ (e.g., add .metpy.to as an alias for .metpy.convert_units) so analogous code works on both accessors
• don't seek full replication of these other accessors' features or creating a dependency on them at this point, but keep such issues in mind leading up to v2.0 (see Future reconsideration of features on MetPy's xarray accessor and its place in the ecosystem #2364)