Shipping infrastructure and generic implementation (OCC-60)

Shipping is a very complex feature set, that may not be necessary in the minimum feature set, but is vital to many if not most businesses.

1. The feature must allow for multiple shipping providers to be active and contribute at the same time.
2. Specific implementations may rely on external web services, and as such must be async and fault-tolerant.
3. Product dimensions (weight, volume, length, width, and height, as well as maybe a flag for unusual shapes) can be stored on a Dimensions part that can be added to products and that is not implementation-specific.

A generic implementation would likely be mostly manually operated, and would be a place to store external tracking links, shipping provider name, and simple pricing determination based on weight and volume intervals. It should not attempt to be too sophisticated, as that would likely imply specialization that should really live in provider-specialized extensions.

Note: there exist Stripe-like shipping broker services that could also be good first implementations or extensions to build.

Jira issue

No files, tests, or entry points are named. Start by surveying the repository for existing product, provider, and asynchronous integration abstractions, then review the Jira issue and the requirements for Dimensions, multiple providers, fault tolerance, tracking links, and basic pricing. Done would require an agreed scope and a complete generic shipping design, including extension points for provider-specific implementations.