Reroute hiera_xxx functions to the new lookup logic

The hiera_xxx functions are currently hardwired directly to Hiera 3 and the global data layer. They should instead be rerouted to use the new lookup logic as follows:

• If the environment has no hiera.yaml the calls to hiera_xxx continues to work as before.
• If the environment has a hiera.yaml this is taken as a signal that the user has opted in to the new behavior. The hiera_xxx functions now operate across all layers. At the same time, if there is logic that makes use of the hiera "override paths" functionality an error is raised as that feature is incompatible with hiera 5.
• If the global hiera.yaml is version 5 the same rules apply as if there is an env's hiera.yaml.

The motivation for this is:

• This replaces the earlier idea that users must reroute their hiera_xxx with overrides in site.pp as that just makes users that opt-in having to opt-in twice.
• Users must be able to lazily migrate environments and modules
• The set of users that have modules that use "override-paths" in explicit hiera calls in modules they do not have control over is expected to be very low
• Out of the box behavior is unchanged except if users have opted in to hiera.yaml v4 in their environments. Since that feature is experimental we have the right to change the behavior. At the same time, the set of users having opted in to hiera.yaml v4 and also using hiera calls with "override-paths" is an even smaller group of users (probably none).

The upside for users is that migration to hiera.yaml v5 in environments as well as global can be performed without also having to update all modules w.r.t hiera_xxx calls at the same time.

The lookup logic must be enhanced in two ways to accommodate the new requirements. It must be possible to:

• do a lookup that involves only the global layer.
• add new overrides (hierarchy paths) directly in a call (for the case where the hiera.yaml is v3 and there is no heira.yaml in the env).