Rework Policy engine to support additionalTypeInstances and tidy up syntax

[mszostok]

Description

Currently, we are not able to pass additional TypeInstances in an obvious way. This task is about adjusting Policy to support more use-cases that are useful when working with Capact.

Acceptance Criteria

There are three different areas to improve. We can treat them as subtasks:

• Required TypeInstances (4SP) @pkosiec
• Additional TypeInstances (4SP) @pkosiec
• Additional Parameters (4SP) @mszostok

Required TypeInstances (4SP)

1. Required input TypeInstances for Implementation (e.g. aws account): 3SP
   • update documentation
   • consider if name should be specified or not
   • consider if TypeRef should be specified or not. We can still have it but as a metadata, or just validate that the given typeInstance is of specified type. The reason for that is an example where user defines implementationConstraints base on attributes and doesn't know exact alias for a given TI. What he wants to do, is to simply say prefer AWS solutions and here is AWS account that should be used.

   rules: # Configures the following behavior for Engine during rendering Action
     - interface: # Configures a second rule in the Action policy
         path: cap.interface.database.mongodb.install
       oneOf:
         - implementationConstraints:
             path: "cap.implementation.bitnami.mongodb.install"
           inject:
             # additionalParameters - for `additionalInput.parameters` 
             # additionalTypeInstances: - for `additionalInput.typeInstances`
             requiredTypeInstances: - for `requires`
                 - id: uuid
                    description: "GCP SA" # optional

2. Remove apiVersion from Policy
3. Update ListImplementationRevisionForInterface to ignore Implementation which has requiredTypeInstances but user didn't specify them in Policy. 1SP, split to: When looking for an Implementation renderer considers all TypeInstances available in the system #358

Additional TypeInstances (4SP)

1. Input TypeInstances specified for the Interface are used only for Interface Implementation.
   • Remember to update the validation process, as currently we ignore unknown TypeInstances. 1SP
2. Additional Input TypeInstances for Implementation (e.g. already existing database) are specified under policy. 3SP
   • update documentation

     - interface: # Configures a second rule in the Action policy
         path: cap.interface.database.mongodb.install
       oneOf:
         - implementationConstraints:
             path: "cap.implementation.bitnami.mongodb.install"
           inject:
             additionalTypeInstances:
                - name:  "name"
                   id: ${TI_ID}

Additional Parameters (4SP)

1. Rename the inject.additionalInput to inject.additionalParameters. 1SP

   • Remember to update examples, tutorials, manifests etc.

   rules: # Configures the following behavior for Engine during rendering Action
     - interface: # Rules for Interface with exact path
         path: cap.interface.productivity.rocketchat.install
       oneOf:
         - implementationConstraints: # Enforces the Helm RocketChat Implementation
             path: "cap.implementation.rocketchat.helm.install"
           inject:
             additionalParameters: # Injects additional parameters for the Implementation 
               - name: additional-parameters:
                 value:
                   replicaCount: 3

2. Require parameter name under the additionaInput.parameters property definition in Implementation. 3SP

Reason

The current implementation was good enough, but new use-cases are more sophisticated. Additionally, we want to make current syntax more readable ad usable.