Reduce build size with dead code elimination

[zemzale]

Based on discussion in 1496 a experimental change to allow reducing the build sizes.

This adds a build tag novalidatefn that makes any usage of validateFn panic. The idea is that we can eliminate calls to tryCallValidateFn that in turn uses field.MethodByName that can't be dead code eliminated.

This is more of POC for now, with showing how this could be done. If we are okay with this change I will update the docs and any other thing that is required for this to actually ship.

[vincentbernat]

I think the build tag should be validator_novalidatefn to avoid collision.

[sverdlov93]

We ran into this exact issue at JFrog while optimizing our Go service binary. Here's our analysis confirming the impact:

Our setup: ~1,480 packages, 99 MB binary (Linux amd64). We use validator.New() with custom tags but never use validateFn.

What whydeadcode shows on our binary today:

github.com/go-playground/validator/v10.tryCallValidateFn reachable from:
   github.com/go-playground/validator/v10.isValidateFn
   github.com/go-playground/validator/v10.isValidateFn·f
   github.com/go-playground/validator/v10.map.init.11
   github.com/go-playground/validator/v10.bakedInValidators
   github.com/go-playground/validator/v10.New

Reviewed the code in this PR — it addresses the issue correctly. The MethodByName call moves into no_validate_fn.go (default build), and -tags validator_novalidatefn compiles only the panic stub. The registration in baked_in.go stays in both paths, but the stub prevents MethodByName from appearing in the linker's reachability graph.

The build tag naming validator_novalidatefn is good — prefixed with the package name, consistent with how gin does nomsgpack. Would be great to see this land!