Proposal for processing an external trusted OID yaml file

* This patch is a proposal(that's why filename is hard-coded) that allows trusted facts users to map their
custom OIDs to user-friendly names that can be used in puppet manifests.

For instance a mapping file such as

```
# /etc/puppet/trusted_oid_mapping.yaml
---
oid_mapping:
  - ['1.3.6.1.4.1.34380.1.2.1.1', 'shortname', 'Long name']
  - ['1.3.6.1.4.1.34380.1.2.1.2', 'othershortname', 'Other Long name']
```

could be used to obtain `$trusted[extensions][shortname]`.


* If the oid mapping is not done at this level, each site that wants to
use custom trusted facts extensions would have to write its own
`oid_to_name` puppet function that traverse the `$trusted[extensions]`
hash and replace _OIDs_ with friendly names.

_Note_: I couldn't succeed to add a configuration option for this as the
`puppet/ssl/oids` library seems to be loaded very early and I don't have much time to dig deeper.
This is probably evaluated when `require 'puppet'` is called, which is extremely early and is why you're probably not seeing any setting being respected. The other OIDs can be registered at require time because they're a static list of OIDs, but this same approach can't be used for custom OIDs.

One option for this is to move this code into a method, and invoke it by adding a setting for the file, and using a hook (https://github.com/puppetlabs/puppet/blob/master/lib/puppet/defaults.rb#L135) to invoke that method. This means that if the setting is actually supplied then the settings initialization will invoke the method which can then load the custom OIDs.