API responses without children are not instantiated correctly but used as string value

[kkmuffme]

While response models with children use the correct class with namespace as they are checked against the namespace: https://github.com/intuit/QuickBooks-V3-PHP-SDK/blob/a4039a8257633ed1481dfe1e50a7881016fa0b1d/src/XSD2PHP/src/com/mikebevz/xsd2php/Bind.php#L156C51-L156C51

This code is missing here for the case where it doesn't have any children: https://github.com/intuit/QuickBooks-V3-PHP-SDK/blame/a4039a8257633ed1481dfe1e50a7881016fa0b1d/src/XSD2PHP/src/com/mikebevz/xsd2php/Bind.php#L180

Therefore the class never exists and classes like Enums, IPPReferenceType,... are never used in the response. This then causes bugs like https://github.com/intuit/QuickBooks-V3-PHP-SDK/issues/477 and also cause the PHP response not to match the docs in the API explorer https://developer.intuit.com/app/developer/qbo/docs/api/accounting/all-entities/account at all.

This is a simple fix and it would make the SDK to be correct, however this would be a breaking change, since the SDK then actually works how it's documented (@var)

[kkmuffme]

This bug causes ALL update operations that do not use "sparse" true to potentially delete fields that are not included (https://github.com/intuit/QuickBooks-V3-PHP-SDK/issues/477) Subsequently, this means you cannot delete any field (as this cannot be done with "sparse", as setting it the field to null will just skip/not update the field when sparse is true) without risking to delete other fields you didn't intend to, since the API response is incomplete.

EDIT: and to make matters worse, the Facades (e.g. create) will CORRECTLY create those types, so you'll end up with complete chaos - bc the Facades will correctly create the type, but the response has incomplete types.