[WIP] Implement design system button

[NoelDeMartin]

This PR introduces a first draft for how we could implement components moving forward, following the design system from Figma.

Some things to note:

• Variable names are aligned with Figma naming, and included in this package (in src/design-system/styles/main.css). The current global variables should be removed from mashlib, and if needed for reuse, we could export them from this package in some way.
• I just placed them in a design-system folder temporarily, once we settle on the final conventions and start migrating all components we should think about folder organization and how to import/export various bundles.
• After some research into other projects using Lit (Web Awesome, Home Assistant), it seems like it's standard practice to couple component registration with implementations (meaning, we will export bundles with side-effects). We can still think about this, but seeing how other projects do it, maybe we should use a different approach for tree-shaking that isn't removing side-effects.
• I have also implemented a proposal for using icons moving forward, see src/design-system/lib/icons and how icons are rendered (using <icon-lucide-plus>, etc.). The main drawbacks is that we still have to import individual icons, rather than being resolved individually. Otherwise we could import the entire icon collection. But I haven't found a way to resolve this dynamically using web components.
• I have created a new storybook for the new component, which is aligned with the examples in the Figma design. Looking over the other existing storybook entries, many seem broken or outdated; so maybe it would be a good idea to clean them all up and start from scratch. Ideally, every component variant/property combination would be showcased in storybook. Because of that, the current button implementation is quite simple (just has 3 variants and icon slots). I'd rather start like this and adding component complexity as needed, rather than trying to implement a complex button from the beginning.

So, this is still a draft but I think it's very close to what I'd like to have eventually. So now it would be a good point to give feedback if there is anything at all you don't like about this PR :).

PS: You can see a temporary deployment of the storybook for this code here: https://noeldemartin.github.io/solid-ui/?path=/docs/design-system-button--docs

[timea-solid]

In general it looks fine for me. Thank you for doing the research.'
The icon usage seems a bit 'clunky' so I hope for a more elegant solution.

Are we going to use https://github.com/SolidOS/solid-assets for global variables?

[NoelDeMartin]

The icon usage seems a bit 'clunky' so I hope for a more elegant solution.

Can you elaborate what you mean? Is it the fact that we have to import each icon individually? Or you don't like the idea of having a web component for each icon?

To clarify, this is how we'd use icons with this new approach:

<solid-ui-button>
    Confirm
    <icons-lucide-check></icons-lucide-check>
</solid-ui-button>

If you're looking at the code in the storybook, that is indeed more confusing than this. But that's only because we are trying to render icons dynamically. And maybe it could be done more elegantly, but given that it's just storybook code I don't care about it as much as production code.

The real problem I would agree with is the need to import each icon, as I mentioned... But I'm not sure it's easy to solve with our current setup, unfortunately :(. Other than that, this is very close to how I've been using icons in my apps for years and the DX is pretty good (we could also configure that <i-* prefix instead of <icons-* if we want).

Are we going to use https://github.com/SolidOS/solid-assets for global variables?

I didn't know the variables came from there, I thought they were defined in mashlib. In any case, they should definitely be declared in a single place, and imported from whatever packages publishes them elsewhere. I would vote for exporting them from this package (solid-ui), given that it's where they're going to be used the most since this repository should define the foundations of the design system. But if we still want to keep it on solid-assets, that's fine, I can also make a proposal to show how we could export/import them to keep a single source of truth.