Allow easier addition of custom facts for Transports

Use Case

When managing network devices, customers want to enrich the collected facts with locally relevant information. Since the device facts don't go through facter (and require custom access to the transport anyways) there is currently no good way to inject custom facts.

Describe the Solution You Would Like

With Resource API Transports, we now have a place to inject facts programmatically: https://github.com/puppetlabs/puppet-resource_api/blob/b8d8817e1f007f98089331e1d2079c8d9aa70b72/lib/puppet/resource_api/transport/wrapper.rb#L31-L35

Modifying this function allows us to add more functionality into the fact-processing code path at will.

Since we can make no general assumptions about transport APIs, the main fact API is a mutate_facts(context, facts) -> Hash method that allows arbitrary changes to facts data. A simpler and safer option would be additional_facts(context) -> Hash which can only add facts.

For the significant class of SSH/CLI based Transports, we also want to implement a data-based way to add facts. In this case the transport would need to declare a command_based feature flag and provide a execute_command(command) -> output function. A command-based fact then would be a YAML file similar to this:

# some_fact.yaml
---
name: value_fetch
command: "show version"
pattern: "some weird regexp fetching values from the output"

which would create a new fact value_fetch which contains the matched values from show version using the pattern regular expression. Might also use named capture groups for building a Hash.

Any custom facts need to be able to be deployed through a different module than the one implementing the Transport.

Additional Context

This has been regulariy requested by networking customers.
There is some internal prior work: see FM-7071, FM-8086, FM-7931, https://github.com/puppetlabs/puppet-resource_api/pull/105 and some more.

Start with lib/puppet/resource_api/transport/wrapper.rb at the linked fact-processing code, then review pull request #105 and the referenced internal work. Compare the proposed mutate_facts, additional_facts, and command-based approaches, including deployment through another module; done requires an agreed implementation scope and a verified custom-fact mechanism.