fix: Card components no longer require explicit children prop with ch…

[fredguevs]

Motivation

This PR addresses an issue where Card components in react-native-paper require an explicit "children" prop even when child views are provided through standard JSX syntax. The current implementation causes problems when non-Card components (like View) are used as direct children, as they receive props they can't handle.

Related issue

Fixes #4684: Card Components require "children" prop despite child views

Test plan

I've tested the changes with the following scenarios:

• Standard Card with Card.* components (Card.Content, etc.)
• Card with custom View component as direct child
• Mixed Card and non-Card components as children
• Deeply nested components inside Cards

Reproduction for Issue #4684:

• This example demonstrates the issue where Card components need an explicit "children" prop even when they have child views.
• Current behavior: The card components demand explicit "children" prop even with child views.
• Expected behavior: The card components should not require "children" prop when child views are present

``

  {/*` Problem: This will throw an error */}
  <Card mode="elevated">
    <Card.Content>
      <Text>Card with child views but no children prop</Text>
    </Card.Content>
  </Card>
  
  {/* Workaround: Explicitly passing children prop */}
  <Card 
    mode="elevated"
    children={
      <Card.Content>
        <Text>Card with explicit children prop</Text>
      </Card.Content>
    }
  />

``

The fix modifies how the Card component handles children by only passing special props to known Card sub-components (Card.Content, etc,) and leaving other components untouched.

[callstack-bot]

Hey @fredguevs, thank you for your pull request 🤗. The documentation from this branch can be viewed here.

[satya164]

This also means:

• You can't wrap CardContent, etc., in another component, it needs to be direct child
• You can't provide your own implementations of these components, it can only be the premade ones

These makes this change a breaking change and makes them less flexible.

To avoid the issue of passing unnecessary props, it could wrap each item in a context provider instead, tho that's also a breaking change.

Also not sure how this PR addresses the type error in the linked issue since these changes are runtime code changes which shouldn't affect typescript errors.