Standardize way to access SKU fields by providing a dedicated EntityWithSkuInterface

Generally fine with the change, only thing that's making me hesitant as discussed in Slack is the return types... Just trying to avoid breaking existing code, but that is probably fine because this targets 3.0.x.

If we make the change, we should as well specify "static" as the return type for the setter. And we need to investigate the test failures.

It looks quite random, that the tests fail here and not in general:

Drupal\Tests\commerce_product\Functional\Jsonapi\ProductVariationResourceTest::testIndividual
The 'errors' member was not as expected.
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
 Array (
     0 => Array (
-        'detail' => 'title: Title: this field cannot hold more than 1 values.'
+        'detail' => 'sku: The SKU "ABC123" is already in use and must be unique.'
         'source' => Array (
-            'pointer' => '/data/attributes/title'
+            'pointer' => '/data/attributes/sku'
         )
         'status' => '422'
         'title' => 'Unprocessable Content'
     )
+    1 => [...]
 )

That's part of the core's jsonapi base class test testPostIndividual(). Entities with a label key are posted twice, in order to trigger the "field cannot hold more than 1 valoues" error for the title field. As the SKU field has a unique constraint, we also trigger this error. I wonder, why this works for the regular branch, but not for this MR

I would feel much better if we had any kind of testing included in the MR that would fail if we accidentally introduce regression in the future (change interface name, namespace, signature, etc). I believe https://git.drupalcode.org/project/commerce/-/blob/3.0.x/modules/product... is a good candidate where the interface can be checked. This way if we ever mess up with it, at least we have a asset somewhere in our test suite.