Allow secrets in `Header.authorization_basic` and `Header.authorization_bearer`

[radeusgd]

We do allow Secrets in our 'plain' headers, like Header.new "Name" secret_value, but currently the two helper methods used for authorization where secrets would be most useful do not accept them.

This is due to the fact that to construct the actual header payload, these two helpers need to append a 'non-secret' prefix to the secret value or even perform a Base64 encoding of the transformed value, and such manipulations of secrets were not currently supported.

We probably need to implement a simple set of operations that can be performed on secrets. We should not allow performing arbitrary Enso operations on secret values, as that would be a too easy way to leak the actual values. Instead, we may need to create some simple DSL for derived secrets, i.e.:

type Derived_Enso_Secret
    Constant txt:Text
    Secret secret:Enso_Secret
    Concat lhs:Derived_Enso_Secret rhs:Derived_Enso_Secret
    Base_64_Encode value:Derived_Enso_Secret

using that, we could allow such derived values to be used and then computed on the Java side.

[enso-bot[bot]]

Radosław Waśko reports a new STANDUP for the provided date (2024-01-12):

Progress: Implemented Derived_SecretValue to allow using secrets in `Header.authorization{basic|bearer}`. Implemented local binding propagation in type PoC + a prototype for checking function argument types. It should be finished by 2024-01-16.

Next Day: Next day I will be working on the #8722 task. Allow secrets in AWS_Credential