Allow the Apache service state to be unmanaged

[greatflyingsteve]

Describe the Bug

Starting in v8.0.0 with this commit, it is no longer possible to leave the Apache service state explicitly unmanaged. The allowable values for $service_ensure are restricted in that commit to only the values that the Service resource will accept on its ensure parameter. This is passed through to the Apache::Service class's parameter of the same name, which still to this day would accept alternative values for that parameter if it were possible to pass them, and simply result in the service state remaining unmanaged. Because this is an explicit param pass, and because the default value is 'running', it is not possible to override this parameter via Hiera, nor is it possible to override this with a non-value, because e.g. passing undef to the parameter via a resource collector is equivalent to passing no parameter value at all. [Edit: actually this works okay, but it's still gross and kinda makes my skin crawl.] There should be a clean way to use this module to simply configure Apache and leave service state to another tool.

Expected Behavior

Allow the Apache service state to be explicitly unmanaged, so that external tools like Ansible, Bolt, or other service management tooling used in more complex deployments are able to manage the service state, instead.

Steps to Reproduce

Steps to reproduce the behavior:

1. Attempt to pass any value other than a valid service state to the Apache class's service_ensure parameter (we used 'unmanaged' for this previously)
2. Apply this configuration to any host
3. Observe the resulting catalog compilation failures

Environment

• v8.0.0 or later (issue is still visible in current tip of main) w/ Puppet 7.x or 8.x
• CentOS 9 (though a quick read of the code shows this would be the case on any platform)
• Unit tests via PDK 3.3.0

Additional Context

I will try to submit a PR for this soon, but wanted to at least get this issue filed.