[Feat]: Custom / External Attestors

[ChaosInTheCRD]

Describe the solution you'd like:
Currently, users have a selection of attestors that they can run with Witness, which all reside inside of go-witness.

If a Witness user wishes to generate other kinds of attestations, their only option is to contribute that attestator to the go-witness library. This however is good because it means that all witness users benefit from this new functionality.

However, there are scenarios in which this might not make sense:

1. Attestor logic already exists in another repository, either written in another language or written in a way that doesn't offer well to being integrated as a Witness attestor.
2. A Witness user has a need to create custom predicates that are specific to their specific use-case, with no wider relevance to the public (e.g., attestations for specific business logic).

Therefore, this issue introduces the concept of custom or external attestors that can be created by users / contributors in other repositories, before being compiled and used by witness during the Witness run process.

[mikhailswift]

There are two sides of this issue to consider here:

1. Using custom attestors or attestations generated by other tools during policy verification. Currently, the Witness policy engine expects an AttestationCollection and expects to find each Predicate within that collection in the statically compiled Attestor registry. This means that Attestations from other tools, such as a SLSA provenance, cannot be used during policy verification. It also means that Attestations generated by a different version of Witness with an Attestor compiled in that isn't compiled into the version of Witness doing the verification also cannot be used.
2. Generating custom predicates/Attestors with Witness without the need to statically compile them into a version of Witness, as this issue discusses. The main concern here is establishing sufficient trust with whatever mechanism we have to create these external Attestors/predicates. Dynamically loading Go plugins or shelling out to other processes carries some risk.