Typography component

[daksas303]

Added Typography component Typography have these options:

• Element type (h1, h2 ..., p), all element types have already the default size for mobile and desktop according to Figma https://www.figma.com/file/ctDKMhAPIjLUVNNmq430D4/DS-ESBS%3A-Foundations?node-id=73%3A133&mode=dev
• Element size. same options as element type, plus sizes h1-hero, h1-form, p-small, and p-large. Element size can be set either as single string value size="h1-hero" as such both mobile and desktop sizes will be the same, or you can pass array of exactly two values, first for mobile and second for desktop size={['h1', 'h1-hero]}
• Element variant options define font-weight, light, normal, medium, and bold. Default values are bold for headers and normal for paragraph

For normalizing text we used utility from mestskakniznica. Also for merging tailwind classes, we are using twMerge, which ensures the precedence of tailwind classes that are passed from the user.

[daksas303]

• in general I'm missing a lot of documentation/commentary - what is in PR conversation in here is documentation that belongs to the codebase, along with a few more mentioned in comments below. I'd keep most documentation next to the code as comments.
• I see many more options of text styling available than we want to allow - the goal here is to restrict rather then make it configurable. I.e. headers shouldn't have variants for boldness. I think the only concession we want to make is the ability to separate semantics and styling - that is, to have a h2 semantically but for it to be in the styling of h3.
• other than that, this should allow no more options that you can see in Figma - 7 types of headers (h1-hero to h6) with their mobile versions, without any further variations available + 2 'button' texts + 3 * 4 paragraph variants. So, the 'default' should only be 21 'configurations' altogether of Typography. By the way, the typography figma should be linked in the code as well.
• if there are any particular reasons why we need further customisation or other variants, there should be reasoning for it in code

Following up on all that - I'm not sure if the size + variant approach is correct here. But I'd come to that and the review of component itself after we address the above.

I added commentary to each showcase component about usage and also commented out some possibly unclear types, used utils functions, added figma link, commentary about used prefixes, etc.

Also, I restricted variants via TS to by default allow just the provided options from Figma, so when the user uses for example type="h1" it is now NOT possible to use at the same time variant="light" to change the default font-weight: bold. I tried to explain in comments the usage for each type header, p, and span.

Just to clarify I believe there are actually 22 configurations, because of the H1 form header variant. They are currently all shown on our local showcase page.

Changed the component structure a bit, to make it a bit less overwhelming and more organized.

[mpinter]

@daksas303 thanks :+1: - I get the idea now, will let @radoslavzeman and @MarekBodingerBA go through this. When everyone is down with the "api" of the component we might do some more finetuning.