Feature Request: Enhanced Responsive Classnames Support

Nobody has claimed this yet.

### Feature Request: Enhanced Responsive Classnames Support

#### Description
I am a developer who heavily utilizes `clsx` along with Tailwind CSS for my projects. The combination of `clsx` and Tailwind CSS is incredibly useful for managing dynamic class names. However, I have found that writing responsive Tailwind class names can be cumbersome and less readable.

#### Current Practice
Currently, I write responsive Tailwind class names like this:
```jsx
className={clsx(
"bg-[#2A2A2A] rounded-[16px] py-[24px] px-[16px]",
"sm:px-[54px] sm:py-[40px] sm:rounded-[16px]",
"md:px-[70px] md:py-[40px] md:rounded-[26px]",
)}
```
This approach works, but it can become difficult to manage and read as the number of responsive breakpoints increases.

#### Proposed Feature

I propose adding support for a more readable and isolated approach to responsive class names, similar to the following:
```jsx
className={clsx(
"bg-[#2A2A2A] rounded-[16px] py-[24px] px-[16px]",
{"px-[54px] py-[40px] rounded-[16px]": "sm"},
{"px-[70px] py-[40px] rounded-[26px]": "md"},
)}
```
or
```jsx
className={clsx(
"bg-[#2A2A2A] rounded-[16px] py-[24px] px-[16px]",
"sm:{px-[54px] py-[40px] rounded-[16px]}",
"md:{px-[70px] py-[40px] rounded-[26px]}"
)}
```
Such formats would allow developers to isolate responsive class names and make the code more readable and maintainable.
I recognize that the maintainers have a deep understanding of the library’s architecture and may know of even more efficient ways to integrate this functionality.

#### Benefits
- Improved readability and maintainability of responsive class names
- Easier isolation of responsive styles for better debugging and testing
- Enhanced developer experience when working with Tailwind CSS and clsx

Thank you for considering this feature request. I believe it would be a valuable addition to clsx, especially for developers who use Tailwind CSS extensively.

Best regards,
Abzal Slamkozha

The issue names no files, tests, or entry points. Start by reviewing the clsx API and the proposed responsive syntax, then determine whether the requested transformation belongs in clsx; done would require an agreed syntax, implementation scope, and tests covering the supported forms.

Written by the indexing model from the issue text.