Add support for deployed custom B2B Buyer Portal based on env vars

[CNanninga]

What/Why?

Using the B2B Buyer Portal in a headless storefront can involve loading the Buyer Portal assets from one of three sources:

1. The official hosted Buyer Portal
2. The Open Source Buyer Portal running in a local environment
3. The Open Source Buyer Portal deployed to a remote host

Each has a different set of scripts.

Catalyst currently 1 and 2, conditionally including the right loader scripts based on the presence or absence of LOCAL_BUYER_PORTAL_HOST. What's needed is support for 3.

This PR introduces an env var for the base URL of the deployed custom Buyer Portal and introduces a third loader style that incorporates this.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 75e9dbf

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

@CNanninga is attempting to deploy a commit to the BigCommerce Platform Team on Vercel.

A member of the Team first needs to authorize it.

[matthewvolk]

Just one comment, and then one smaller nitpick to consider. After that, this will look good from my end 👍

[CNanninga]

Ready for re-review

[bc-micah]

Looks good - some minor comments / questions.

[bc-micah]

Is the idea that the hashes are hard coded - so that they can be versioned through the code?

I guess that would make it easier if you open a PR - you can test out the custom build without having to change env vars for that branch alone.

Suggested change

	const hashIndex = null;
	const hashIndexLegacy = null;
	const hashPolyfills = null;
	const hashIndex: string | null = null;
	const hashIndexLegacy: string | null = null;
	const hashPolyfills: string | null = null;

[CNanninga]

Matt and I had some discussion about this, and for now it didn't seem like it was worthwhile to represent these as environment vars. What we expect to be a common workflow is for devs to deploy their custom Buyer Portal build files with Catalyst (as static files in public), so a new code deployment is commonly needed anyway. (And having the hashes in env vars actually means a code re-deploy and then another re-deploy after updating vars.)

What I opted to do instead was just separate them out very conspicuously in this file.