`getFlagRef` panics on custom `pflag.Value` wrappers with value-backed `value` fields

`fangs` panics while generating a configuration summary when it encounters a custom `pflag.Value` where the implementation is a pointer to a struct, but the underlying value backing the implementation is _not_ a pointer.

This behavior was first noticed in [this issue in `zarf`](https://github.com/zarf-dev/zarf/issues/4338). `zarf` vendors `syft` under `zarf tools sbom` to make it readily available to `zarf` users when operating in an airgapped environment.

When running `zarf tools sbom config`, the vendored `syft` cobra command calls `fangs.SummarizeCommand` which ascends the cobra command graph to the root then walks all config for the entire cobra command tree. `zarf` _also_ vendors `yq` which has [a custom `pflag.Value` implementation: `unwrapScalarFlagStrc`](https://github.com/mikefarah/yq/blob/c14f446382944492701b16c1ddb48bb9dbe683e3/cmd/unwrap_flag.go#L15). This custom implementation backs the value with a plain bool and **not** a pointer, but `fangs` universally derefs the `value` field of any `pflag.Value`-implementing pointer struct type, causing it to panic when attempting to deref the pointer for this scalar.

A clean fix would be for `fangs` to check if a `value` is a pointer before attempting to deref.

Start at getFlagRef and trace the reflection path used for pointer-struct pflag.Value implementations. Reproduce the configuration-summary case with a custom wrapper whose value field is a plain bool; done means summary generation no longer panics for that case.

Written by the indexing model from the issue text.