Resolve Proxy-backed addresses in configuration property traversal

[GrahamCampbell]

This extends the proxy-aware address resolution from #396 to the other ways a value can be addressed once it has been embedded into the configuration. Until now a Proxy-backed object returned by a JS file resolved virtual properties through a file(...) address, but the same value reached through a ${self:...} reference, through the resolveConfigurationProperty util handed to resolver functions and plugin sources, or through serverless print --path, was traversed by own properties only and silently came up empty. All of these paths now follow the same rules: own properties are always followed, Proxy-backed values are followed through their get handler, and proto, prototype and constructor are never followed through a proxy unless claimed as own.

The dependency traversal in the variables resolver and a new getReachableByPath helper used by the print command both build on the canFollowProperty helper introduced in #400, so the rule continues to live in one place. As in #400, a property access that throws during dependency traversal now surfaces as a coded ServerlessError naming the configuration path rather than escaping as a raw exception. The existing getOwnByPath helper is left untouched since its own-only semantics are still what the 3.x print command relies on, and write paths in the resolver intentionally remain own-property-only so that resolution never invokes a proxy's set handler. The variables guide is updated accordingly, replacing the sentence from #399 that described this behaviour as specific to file addresses.

This is deliberately a 4.x-only change: configurations that previously fell back to a default because a proxy-served property could not be found will now resolve the actual value, which is the sort of behaviour shift we would rather not ship to the stable branch.