[Enhancement] Super Icons

[x] I have written a good issue

Describe the enhancement

To further delight the products we are introducing a set of larger icons with more colors and detail. In order to support multiple brands we need a solid and dynamic way to change the icons colors. The icons varies in detail and design in relation to their size. We need way to show different icon svg's depending on the size.

Describe the solution you'd like

UX provides:

3 svg files for each icon variant with seperated paths for areas that need color change

Kirby or DRB provides: See summary of tech refinement below...

Have you considered any alternatives?

Are there any additional context?

Icons - example

Checklist:

The following tasks should be carried out in sequence in order to follow the process of contributing correctly.

Refinement

[ ] Request that the issue is UX refined
[ ] Request that the issue is tech refined; do not proceed until this is done.

Implementation

The contributor who wants to implement this issue should:

[ ] Make sure you have read: "Before you get coding".
[ ] Signal to others you are working on the issue by assigning yourself.
[ ] Create a branch from the develop branch following our branch naming convention.
[ ] Publish a WIP implementation to Github as a draft PR and ask for feedback.
[ ] Make sure you have implemented tests following the guidelines in: "The good: Test".
[ ] Update the cookbook with examples and showcases.

Review

Once the issue has been implemented and is ready for review:

[ ] Do a self-review.
[ ] Create a pull-request. If you created a draft PR during implementation you can just mark that as "ready for review".

Summary of tech refinement with @jakobe

Concept

While this type of icon (illustration?) is conceptually similar to our existing icons, the nitty gritties seem to differ in some key ways.

Even though the screenshot from the issue suggests otherwise, the 'super icons' have no relation to the existing icons. Any existing icon should still have its current implementation of simple scaling of the svg for different sizes.
- E.g. the calendar super icon is a different concept with another default svg
Super icons do not have an xs size, and actual size of sm, md, lg will likely differ from current kirby-icon size.
Multiple svgs exist per super icon, as each size can have small variations, detail levels etc.

Given these differences, and our slightly over-complicated implementation of kirby-icon, we think it is best to implement this from scratch, using ion-icon in a similar fashion to kirby-icon for the time being.

Tech refinement

Colors

ion-icon handles loading the svg from source, which means that the icon svg is inlined inside the ion-icon shadow root. This means we should add part attributes to be able to style the individual paths from the outside. The branded details and colored background of the svgs could be implemented something like this:

<svg xmlns="http://www.w3.org/2000/svg" width="97" height="84" viewBox="0 0 97 84">
    <g fill="none" fill-rule="evenodd">
        <path part="background" d="..."/>
        ...
        <path part="detail" d="..."/>
    </g>
</svg>

This means we can target the details and background for any icon from within the super-icons component styles like this, with a sensible default that still allows consumers to overwrite on the application level or locally per component via --kirby-icon-detail and --kirby-icon-background.

ion-icon::part(detail) {
  fill: var(--kirby-icon-detail, var(--kirby-primary));
}

ion-icon::part(background) {
  fill: var(--kirby-icon-background, var(--kirby-semi-light));
}

Multiple svgs

We should provide a way to register multiple svgs under a specific super icon name, that is automatically selected based on the super icons size.

Some fallback logic should be in place if a specific icon for the given size is not registered - possibly just a 'base' svg that is naively scaled across sizes that have no corresponding svg?

It should be possible to extend the IconRegistryService with functionality for getting icons based on a specific size, given a structure like this:

{
    name: 'calendar',
    base: 'assets/supericons/calendar-base.svg',
    sizes: {
        sm: 'assets/supericons/calendar-sm.svg',
        md: 'assets/supericons/calendar-md.svg',
        lg: 'assets/supericons/calendar-lg.svg',
    },
},

Assets package

Instead of referencing icon assets in a sub-folder we propose to refactor the registry service to instead get super-icons from a new assets package published to npm. This way we avoid having to release kirby each time a new asset is added, but instead Kirby can loosely depend on the assets package that can be released often and with much less friction.

A seperate issue is created for this: #3438

kirbydesign / designsystem