[Shopify] Expose Product facade procedures for Add to Shopify parity

[Franco111000]

What & why

The native Add to Shopify action on the Item Card publishes an item through a specific sequence: it confirms the action and resolves the target shop, checks that the item's attributes are compatible with Shopify product options, adds the item, and resolves the product URL. A partner extending the connector cannot reproduce that flow today, because the relevant procedures live on internal codeunits (Shpfy Sync Products, Shpfy Product Export).

This change exposes the missing steps on the existing public Shpfy Product facade (codeunit 30234):

• ConfirmAddItemToShopify(Item; var ShopifyShop) confirms the add and resolves the shop, including the multi-shop selection prompt.
• CheckItemAttributesCompatibleForProductOptions(Item; ShopifyShop) is the attribute-compatibility check added in v28.
• GetProductUrl(Item; ShopCode) is the item and shop overload of the existing GetProductUrl.

The facade delegates to the existing internal implementations, which stay internal. CheckItemAttributesCompatibleForProductOptions takes the shop on the facade and primes the implementation with SetShop before delegating, exactly as the native Item Card flow does.

Linked work

Fixes #7867

How I validated this

• I read the full diff and it contains only changes I intended.
• I built the affected app(s) locally with no new analyzer warnings.
• I ran the change in Business Central and confirmed it behaves as expected.
• I added or updated tests for the new behavior, or explained below why none are needed.

What I tested and the outcome

• The three procedures are thin delegations to existing internal implementations and carry no new logic of their own.
• Added UnitTestCheckItemAttributesCompatibleForProductOptionsFromFacade (codeunit 139596): calls the facade for an item with more than three "As Option" attributes and confirms it returns false and logs the skipped record, exercising the facade's SetShop and delegate sequence end to end.
• Added UnitTestGetProductUrlForItemFromFacade (codeunit 139604): links a Shopify product holding a URL to an item and confirms the facade returns that URL for the item and shop.
• ConfirmAddItemToShopify is a pure passthrough that shows the existing confirmation dialog, so it is covered by the native action's behavior rather than a new interactive test.
• I rely on CI for the build and full test run; the local .alpackages is empty in this fork, following the AL-Go for PTE pattern this repo uses.

Risk & compatibility

• Additive only: three new public procedures on an already-public facade. No existing signatures change, no breaking changes, no data or upgrade impact, and no new permissions, telemetry, or feature flags.
• The implementation codeunits remain internal.
• Scope note on the page change: issue [BC Idea]: Add requested procedures in facade codeunit to match BC behavior. #7867 also proposed making the Shpfy Add Item Confirm page (30144) setters public. Those setters are internal helpers that the native flow drives only through Shpfy Sync Products.ConfirmAddItemToShopify. Exposing that procedure on the facade gives partners the same entry point the native action uses, including shop selection, while keeping the page's surface internal, so this PR takes that route instead of widening the page. Glad to switch to public page setters if you would prefer to match the issue literally.
• Possible follow-up (out of scope): the native flow also calls CheckItemCanBeExported between confirming and the attribute check. If end-to-end parity is wanted, that procedure could be exposed on the facade as well. Happy to add it if the team prefers.