feat: allow valid Score specs without a containers section and support top level extensions

[astromechza]

We've been looking at how we can use Score to support slightly more abstract workloads and we've seen that the > 1 containers places somewhat of a limitation on what Score implementations can accept and transform and how teams can iterate and learn about Score. This coincides with the need to start supporting additional top level extensions on the spec:

apiVersion: score.dev/v1b1
metadata:
  name: example-workload-name123
x-my-extension:
  archive: http://example.com/binary.tgz
  variables:
    SOME_VAR: ${resources.example.thing}
resources:
  example:
    type: resource-type

[chris-stephenson]

It seems a little too permissive to add this to the score spec as stands. If experimentation is required, a new implementation can always be created.