Discussion: Source Provenance Attribute's allowed types

Generic source provenance, introduced in #2099, only allows support for singular string values. When considering applying source provenance for SPDX, fields such as [externalRefes](https://github.com/spdx/spdx-spec/blob/v2.3/schemas/spdx-schema.json#L313) and [attributionTexts](https://github.com/spdx/spdx-spec/blob/v2.3/schemas/spdx-schema.json#L353) should be arrays. In general more type support, even just arrays would be useful, we don't want to solely cater to SPDX.

BuildStream can't itself restrict types and not care about the attributes themselves without either:
- Accepting everything as lists, strings are a single item
- Allowing for user definition of types per field

The former approach is simpler and *works* but offers no guarantee of correctness and is inaccurate for most cases whilst also tying BuildStream up in specifics instead of being generic. The latter approach is as accurate as users are but at the cost of a more complex implementation and verbose configs (not necessarily a bad thing other than to set up).

There is also the option to simply not type check source provenance attributes at all but this would add more complexity to code such as `bst show` to potentially need to handle literally anything.

Start by reviewing the source provenance implementation introduced in #2099 and the `bst show` handling mentioned here. Compare the proposed approaches for arrays, user-defined field types, and no type checking against the SPDX `externalRefs` and `attributionTexts` examples. Done means a decided, generic type-handling design with its expected configuration and behavior documented.

Written by the indexing model from the issue text.