fix: avoid parsing scalar structs twice

[otrumb]

Fixes #440

Problem

With UseFieldNameByDefault, scalar structs such as url.URL were recursively parsed a second time after the tagged value had already been decoded. This let HOST and PATH overwrite URL internals, and made RequiredIfNoDef demand exported implementation fields.

Fix

Avoid recursive parsing when the field type has already been handled by a scalar parser.

RED evidence

• url.URL became http://evil/usr/bin because HOST and PATH overwrote Host and Path.
• RequiredIfNoDef demanded internal url.URL fields such as SCHEME, OPAQUE, and HOST.

Verification

• go test ./... -count=1
• go test -race -shuffle=on -count=1 ./...
• go build ./...
• go vet ./...

Scope

Two files: parser logic and regression tests.

[karaaslanz]

I traced the new scalar gate against current doParseField semantics and I think the type-level check is a little too broad.
Today an initialized nested *struct with no scalar env key is recursively parsed even if its element type also has a FuncMap parser. This head marks the type scalar before field params are considered, so it skips that existing nested path and then returns after processField even when this particular field had no scalar value to parse.
A focused regression would use the same custom struct type both as a scalar field with env:"SCALAR" and as a preinitialized nested pointer with envPrefix:"NESTED_". On current main, NESTED_VALUE is parsed into the nested field. With this head, the nested pointer is classified as scalar solely because its type is registered in FuncMap; because that field has no own scalar key, nothing is set and the later if scalar { return nil } prevents the nested env from being parsed.
I think the scalar-vs-container decision therefore needs to account for whether this particular field actually has scalar input/default to consume, rather than only whether its type can be scalar-parsed. PR #442 touches the same preinitialized-pointer/FuncMap boundary, so it would also be useful to reconcile its regression with whichever fix is chosen instead of leaving two divergent rules.
Source-level review only; I did not run this branch locally.

[otrumb]

The external report was independently reproduced: RED expected nested nested, got ""; GREEN with this fix.

Rule: scalar-capable structs use the parser only when that field has its own key/default; keyless prefixed pointers recurse. Focused/full CGO=0 tests, go vet, and build pass. PR #442's scalar-key preinitialized-pointer behavior remains preserved.