feat: support binaryContent for inline Score files

[astromechza]

I've been investigating a long standing issue of dealing with non-utf-8 files when normalising a score spec. Normally when we 'normalise' the spec, we convert any files specified via source into inline files with content. However, since the score file itself is utf-8, not any old binary content can be written as valid unicode into the yaml file. It breaks if any non-utf-8 sequences are used, and the user will be left wondering why their file contains magic \xEF\xBF\xBD bytes instead.

I think the solution is instead to allow a separate binaryContent field which clearly contains base64. This is similar to kubernetes config maps which contain a binaryData section alongside the data section and allows for better validation routines and checking in the implementation.

An example score file might look like:

$ openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -sha256 -days 365
$ openssl x509 -in cert.pem -out cert.der -outform der
$ cat score.yaml
apiVersion: score.dev/v1b1
metadata:
  name: example
containers:
  main:
    image: debian
    args:
    - sleep
    - infinity
    files:
    - target: /mnt/cert.der
      source: ./cert.der

This will be supported without trouble in score-compose and score-k8s, and Humanitec may implement an extension to their existing "variables" with a similar base64 marker or alternative.

[mathieu-benoit]

LGTM