Add new design pattern documentation page for cards

[jtamiace]

Product

All

Desired behavior

This is the design pattern version of https://github.com/learningequality/kolibri-design-system/issues/263

The hybrid learning project saw several new variations of cards introduced to the learning platform. Until now, we have loosely followed Material Design standards for cards, and at this point, it would be helpful to document the unwritten patterns we've adapted under our own constraints.

Some of these patterns are as detailed as the specific border radius, drop shadow, and padding that are used on cards. Other patterns are related to experience: what kinds of actions/information should be there in the first place and in what visual hierarchy.

(Optional) The Value Add

Cards are ubiquitous in our products and it would be helpful to know what variations are possible and encouraged without having to dig in the products for that information. Non-exhaustive list why this page would be helpful:

1. Provide guidance in any refactors of existing cards to become updated with current guidelines
2. Clear direction for the anatomy of new cards in future design work
3. Clear do's and don'ts on applying existing KComponents, color, and typography within cards

(Optional) Possible Tradeoffs

The layout variation that cards can have is a double-edged sword for the design system. The most important factor is that the card design can be applied to best serve the need at hand. We need to find the right balance of flexibility and consistency with other KComponents or KDS patterns that may also appear in the card.

We should avoid creating and enforcing dogmatic guidelines that prioritize the ease to develop/maintain over a design that appropriately emphasizes relevant information for a particular use case whether that's image vs text vs actions, etc. On the other hand, guidelines that are too flexible run the risk of - at the extreme - having only unique card instances that are time-consuming to update and maintain, or disrupt people's expectations and flow while they interact with our products due to inconsistent information displays.

[indirectlylit]

We can leave them separate for now, but I could also see some benefit in making this and #263 a single issue. We can make a feature branch with both design and engineering contribution which would ensure that the patterns and components are well-aligned

[MisRob]

I will take care of what I can in scope https://github.com/learningequality/kolibri-design-system/issues/264

[MisRob]

@jtamiace I think I may have resolved larger part of this issue in https://github.com/learningequality/kolibri-design-system/pull/785, but not sure if that's exactly what you intended here - would you please have a look?