build: add component size check

[tomdavies73]

Proposed behaviour

Adds a component size check which can be observed locally. Intended to help devs in checking sizes in component changes during development. Whilst not indicative of bundle size it can be used as a measurement to track if component size changes are intended.

Will also never block PRs, only to be used as a supplementary check when needed.

Locally via npm run component-size-check:

Current behaviour

Currently, there is no standardised way to check component size differences easily and quickly.

Checklist

• Commits follow our style guide
• Related issues linked in commit messages if required
• Screenshots are included in the PR if useful
• All themes are supported if required
• Unit tests added or updated if required
• Playwright automation tests added or updated if required
• Storybook added or updated if required
• Translations added or updated (including creating or amending translation keys table in storybook) if required
• Typescript d.ts file added or updated if required
• Related docs have been updated if required

QA

• Tested in provided StackBlitz sandbox/Storybook
• Add new Playwright test coverage if required
• Carbon implementation matches Design System/designs
• UI Tests GitHub check reviewed if required

Additional context

Testing instructions

[ibutakova]

Tracking size regressions looks to be very helpful.

Although right now, summing up .js files ignores the dependency graph. It might flag harmless tree-shakeable code or miss a massive dependency outside the folder, which makes the output hard to trust.

I see here two ways to play, depending on what you want to do:

1. Stick to this but automate a faster, dedicated ESM build so devs don't wait on full npm run.
2. Pivot and measure the actual consumer bundle impact (using a temporary entry via the public API, bundling it, and diffing raw/gzip sizes against the merge base). I'm leaning toward this one)) Carbon has a real reason to understand changes that add or replace dependencies, modify public exports, introduce optional features or affect widely shared utilities.

There's a chance I missed the scope. Anyway, regression tracking rules. Let me know if these thoughts actually fit our workflow