Remove conflicting serde attributes from single-field structs

[oguzkocer]

Summary

Removed #[serde(transparent)] and conflicting #[serde(rename)] attributes from single-field wrapper structs.

Changes

• Removed #[serde(transparent)] from 6 structs:

  • UserCapabilitiesMap
  • PostTypeSupportsMap
  • SparsePostTypesResponse
  • SparseTaxonomyTypesResponse
  • SparseMenuLocationsResponse
  • SparsePostStatusesResponse

• Removed #[serde(rename)] from UserCapabilitiesMap and PostTypeSupportsMap

Rationale

For single-field structs, #[serde(flatten)] on the field is functionally equivalent to #[serde(transparent)] on the struct.

#[serde(transparent)] is not supported by:

• WpContextual (generates concrete types without transparent)
• WpDeserialize (explicitly rejects transparent attribute)

#[serde(rename)] conflicts with #[serde(flatten)] which takes all keys from the parent object.

[wpmobilebot]

XCFramework Build

This PR's XCFramework is available for testing. Add to your Package.swift:

.package(url: "https://github.com/automattic/wordpress-rs", branch: "pr-build/1271")

_{Built from 07aa8ab}

[jkmassel]

I think this approach could fail (though it's probably unlikely).

For example:

// wp_api/src/post_types.rs — inside mod test {}
#[test]
fn test_post_type_supports_map_from_empty_array() {
    // WordPress returns `[]` instead of `{}` when a post type has no
    // supported features (e.g. `register_post_type('foo', ['supports' => false])`).
    let json = r#"[]"#;
    let supports: PostTypeSupportsMap =
        serde_json::from_str(json).expect("Should handle empty array from WordPress API");
    assert!(supports.map.is_empty());
}

// wp_api/src/users.rs — inside mod tests {}
#[test]
fn test_user_capabilities_map_from_empty_array() {
    // WordPress returns `[]` instead of `{}` when a map is empty.
    let json = r#"[]"#;
    let caps: UserCapabilitiesMap =
        serde_json::from_str(json).expect("Should handle empty array from WordPress API");
    assert!(caps.map.is_empty());
}

It's probably vanishingly rare, but I think we need to handle the empty case?

[oguzkocer]

@jkmassel Thank you for catching that. I'm working on a different way to address this conflict, so I'll close this PR and open a new one when I am ready. I'll also make sure to add the tests you provided so they are part of our coverage.

[oguzkocer]

#1273 should address the issues.