Only warn once about table deprecations

[RasmusKjeldgaard]

Which issue does this PR close?

This PR closes no issue

What is the new behavior?

We accidentally warn about table row and selectable deprecations for each instance of the table row component, which is of course not ideal for a component such as table with many individual rows:

A drawback of this solution is that we only warn for the first table that is instantiated in an application, but I believe it is a significant improvement as opposed to warning over and over again.

Does this PR introduce a breaking change?

• Yes
• No

Are there any additional context?

Checklist:

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

Reminders

• Make sure you have implemented tests following the guidelines in: "The good: Test".
• Make sure you have updated the cookbook with examples and showcases (for bug fixes, enhancements & new components).

Review

• Determine if your changes are a fix, feature or breaking-change, and add the matching label to your PR. If it is tooling, dependency updates or similar, add ignore-for-release.
• Do a self-review.
• Request that the changes are code-reviewed
• Request that the changes are UX reviewed (only necessary if your PR introduces visual changes)

When the pull request has been approved it will be merged to develop by Team Kirby.

[jakobe]

👌🏻