fix: parsing vApp properties while converting from OVF envelope to VM ConfigSpec

[hpannem]

Description

When building a VmConfigSpec from an OVF envelope (Envelope.toVAppConfig), vApp property default values were assigned verbatim from the parsed OVF without any type-aware processing. This caused a correctness bug for boolean properties: the OVF envelope uses lowercase "true" / "false", but the vSphere API requires the canonical forms "True" / "False".

This change introduces ovf/vappconfig_parser.go, which implements type-aware parsing and validation of vApp property values for all OVF property types defined in DSP0004/DSP0243:

Type	Behaviour
boolean	Normalises to "True" / "False"
int	Validates as signed int32; rejects non-numeric or out-of-range values
real	Validates as float64; rejects non-numeric values
ip	Validates as a valid IPv4 or IPv6 address
string / password	Enforces the 64k maximum length
string(N..M) / password(N..M)	Enforces minimum and/or maximum character length constraints
int(N..M)	Enforces numeric range constraints (signed and unsigned)
real(N..M)	Enforces floating-point range constraints
ip:network, expression, unknown	Passed through unchanged (pending future work)

Password-typed properties are handled with care: error messages never include the property value to avoid leaking secrets in logs.

Envelope.toVAppConfig now returns an error if any property value fails validation, surfacing problems at config-spec construction time rather than silently passing bad values to vSphere.

Closes: #3963

How Has This Been Tested?

Unit tests added in ovf/vappconfig_parser_test.go covering:

• All basic types (string, password, boolean, int, real, ip, ip:network, expression, unknown)
• All constrained type variants (string(..N), string(N..), string(M..N), int(M..N), real(M..N), password(..N), password(N..), password(M..N))
• Boundary values (min, max, exact) for all range-constrained types
• Invalid values, out-of-range values, and malformed inputs for all types
• Explicit verification that no password value appears in any error message

go test ./ovf/...
ok github.com/vmware/govmomi/ovf 0.403s
ok github.com/vmware/govmomi/ovf/importer 0.198s

[tenthirtyam]

Commit sign-off should use your broadcom.com email.

[hpannem]

Commit sign-off should use your broadcom.com email.

Done.

[tenthirtyam]

I'll fix the issue blocking the CI in another PR in the morning.