Improve UX: Ensure goenv shims or init always prioritize system Go when building or testing goenv

[ChronosMasterOfAllTime]

Opened from #564 @pakar for awareness.

Summary:
To provide a seamless and pain-free contributor experience, goenv's shims or the shell init process (e.g., eval "$(goenv init -)") should automatically detect and prefer the system Go installation when the user is building or testing goenv itself, avoiding recursive shim invocation or confusing bootstrapping scenarios.

Current Situation:

• When working on goenv itself, the user's shell may use goenv's own shims even for building/testing goenv, leading to potential self-reference, unexpected behavior, or confusing errors.

Feature Request:

• Improve the goenv UX so that when building or testing goenv (especially as a contributor), the process uses the system-installed Go binary, never a goenv-managed version.
  • This could involve:
    • Making shims or goenv-init smart enough to detect goenv's own repository path or context, and fall back to system Go in such cases.
    • Ensuring eval "$(goenv init -)" never sets up shims for goenv build/test phases.
    • Optionally warn the user if a goenv-managed Go is being invoked on goenv itself.

Benefits:

• Seamless contributor and onboarding experience
• Prevent hard-to-debug bootstrapping issues
• Aligns with contributor expectations for pain-free local development

Additional context:
Feedback welcome on possible approaches (shims auto-detecting repo, init-path exclusion, or other mechanisms).