feat(composables): introduce useDeprecated for deprecated APIs

[jw-foss]

Summary

While we are doing the typescript improvements, I noticed that we have quite a few places were using validator for deprecated APIs, since we are on Vue 3.5 I think it is fair to migrate from that to a composition API.

In this PR, I added a composable named useDeprecated and updated KButton as an example, I also included a test file against the newly added composable.

KM-1149

[netlify]

✅ Deploy Preview for kongponents-sandbox ready!

Name	Link
🔨 Latest commit	aa31c58
🔍 Latest deploy log	https://app.netlify.com/sites/kongponents-sandbox/deploys/67f5e5d603c0350008a0e178
😎 Deploy Preview	https://deploy-preview-2690--kongponents-sandbox.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[netlify]

✅ Deploy Preview for kongponents ready!

Name	Link
🔨 Latest commit	aa31c58
🔍 Latest deploy log	https://app.netlify.com/sites/kongponents/deploys/67f5e5d657dd850008df11e4
😎 Deploy Preview	https://deploy-preview-2690--kongponents.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[kongponents-bot]

Preview package from this PR in consuming application

In consuming application project install preview version of kongponents generated by this PR:

@kong/kongponents@pr-2690

[adamdehaven]

I'm not sure this change is really necessary. We may not want to always watch and continue to log the deprecations, and the logging was only put in place to aid in migration without needing to push breaking changes to the repository.

If we had gone with an approach similar to this originally I think it would have been fine, but I'm not sure it's necessary to refactor at this time

[jw-foss]

I'm not sure this change is really necessary. We may not want to always watch and continue to log the deprecations, and the logging was only put in place to aid in migration without needing to push breaking changes to the repository.

Understood, for the part "we may not want to watch and continue to log the deprecation" I can provide a once watcher for this.

If we had gone with an approach similar to this originally I think it would have been fine, but I'm not sure it's necessary to refactor at this time

For sure, I'll close this PR if this is what we wanted.

[Justineo]

Makes sense either way. I was thinking a consistent way to handle the fraction might be helpful too, if it ends up being reused.