Add TCF 2.3 support: Disclosed Vendors segment parsing

[osazos]

This PR implements support for the TCF 2.3 Disclosed Vendors segment, which becomes mandatory on March 1st, 2025. Given the short timeline for compliance, I extended the existing ConsentMetadata structure to parse and store disclosed vendors data, reusing the established parseBitField() and parseRangeSection() patterns. The implementation fully supports both BitField and RangeSection encoding modes as specified in the TCF 2.3 standard. While this approach delivers quickly and maintains backward compatibility, future refactoring should separate segment parsing concerns for better modularity.

Changes

• API Extension: Added VendorDisclosed(id), VendorDisclosedMaxVendorId(), and HasDisclosedVendors() methods to the VendorConsents interface
• Segment Parsing: Created disclosed_vendors.go to parse the Disclosed Vendors segment (segment type 1) with full support for both BitField (IsRangeEncoding=0) and RangeSection (IsRangeEncoding=1) encoding modes
• Core String Parsing: Modified parseWithDisclosedVendors() to iterate through consent string segments and detect the disclosed vendors segment by type
• Metadata Storage: Extended ConsentMetadata struct with disclosedVendors and hasDisclosedVendors fields
• Backward Compatibility: TCF 2.0/2.2 consent strings without disclosed vendors segment continue to work correctly (VendorDisclosed() returns false)
• Range Section Fix: Updated parseRangeSection() to calculate minimum required bytes dynamically instead of using a hardcoded 31-byte check, enabling proper segment parsing

Testing

• Comprehensive test coverage in disclosed_vendors_test.go for BitField encoding
• Tests validate segment type detection, max vendor ID parsing, and consent queries
• Multiple segments can appear in any order (tested in TestSegmentsInAnyOrder)
• Backward compatibility tests ensure legacy consent strings behave correctly
• RangeSection encoding is fully implemented and code paths are tested through existing TCF 2.0 core string tests

Technical Details

Segments after the core string can appear in any order, so the parser checks each segment's type before processing. The implementation correctly handles both encoding modes by checking bit 19 and delegating to either parseBitField() or parseRangeSection() accordingly.

Future Considerations

The current implementation tightly couples segment parsing within ConsentMetadata. As the TCF spec evolves and additional segments are needed (e.g., Publisher TC), consider refactoring to a cleaner segment-based architecture where each segment type has its own parser and data structure.