Allow a role or *array of roles* for contributor role

[peterdesmet]

This PR extends contributor role from a string to a string OR array of strings and related to #804. Note that enum restrictions on what roles are allowed were already removed as part of #809.

Why

Allowing multiple roles per contributor removes the current drawback where contributors have to be duplicated just because they performed multiple roles for a Data Package. Duplication is annoying for data publishers and software implementations (especially disambiguating contributors that look the same). Allowing multiple roles per contributor is a use case we have in Camtrap DP. Profiles (like Camtrap DP) currently can't extend to allow multiple roles since Data Package requires role to be of type string.

Software implementations

This change has an effect on software implementations, but only if they make use of contributor role and only for (new) Data Packages that provide contributor role as an array. Existing Data Packages (with role as string) are still valid.

• Frictionless Framework should be updated to pass validation for role as array
• Other software implementations that make use of role might have to pick the first element of an array if they only support one role per contributor.

Changes in this PR

To the best of my ability, I made the changes where I think they should be implemented in this repo, but have likely made mistakes.

1. While it is technically possible to just change role from a string to an array (since a single role can be expressed as a array of length 1), I think it is better to allow both, since it is easier for data providers and backwards compatible.

2. I took from inspiration from resourcePath which also allows strings and array of strings: https://github.com/frictionlessdata/specs/blob/6b4009428c141e7308349e113c40f633d9da2bea/schemas/dictionary/resource.yml#L159-L162

   ... and created two extra definitions for role: role and roleArray (in common.yml, alphabetically after licenses and before source).

3. The items for roleArray expect a role, so that any added requirements for role are immediately adopted for roleArray items as well.

4. Minimum one value is expected for roleArray

5. I updated the description of role in data-package/README.md

[roll]

CONTINUED in #18