This essentially doubles up the registrations for all of the built-in
functions to have both non-namespaced and core::-namespaced versions of
each function.

This is in preparation for later commits introducing other namespaces,
such as a provider:: namespace which could hold functions that were
contributed by providers that are currently in scope.

The jsonfunction package has special cases for some internal functions,
and wee need to add the namespaced equivalents to those lists.

This is intended as a bridge to functions defined outside of the core
language, which will live in other namespaces in order to avoid ambiguity
with any built-in functions.

For now we only accept provider-contributed external functions. The lang
package doesn't really know anything special about providers, so its only
responsibility here is to enforce the naming scheme that any
provider-contributed functions always live under the namespace prefix
"provider::NAME::", where NAME is a name decided by whatever codepath
instantiated the state as a unique identifier for a particular provider.

This commit also includes updates to the core package to make it possible
to pass in ExternalFuncs in principle, although in practice we don't yet
have any codepaths which do so, and so this is effectively a no-op commit.

We need to be able to reuse providers which are used for function calls,
so cache them in the EvalContext.

This does require a way to close the provider however, which we can do
via the normal root module close node since it already does the same for
provisioners. Update the `CloseProvisioners` method to be a more general
`ClosePlugins` method, and use that to call Close on the cached
providers too.

This establishes all of the wiring necessary for a provider's declared
functions to appear in the hcl.EvalContext when we evaluate expressions
inside a module that depends on a provider that contributes functions.

This does not yet make any attempts to guarantee that the
provider-contributed functions correctly honor the contracts such as
behaving as pure functions. Properly checking this is important because
if a function doesn't uphold Terraform's expectations then it will cause
confusing errors reported downstream, incorrectly blaming other
components for the inconsistency.

Now that we dynamically add scoped versions to the global functions we
can't check the static Descriptions list. This should be OK since the
function descriptions are taken directly from Descriptions list, and if
any other scoped functions were added in the future, they may not be
coming from the current global set of functions anyway.