List types in preferred order in request

[brownhoward]

As only a single channel will be returned, I suggest that the request lists the types in preferred order just in case there is multiple overlap. In this way, the client gets their preferred type that is supported by the server.

Originally posted by @kevin-inrupt in solid/notifications-panel#3 (comment)

[csarven]

Once a client discovers the supported subscription types supported by a notification server, the client only really needs to request the subscription type it prefers.

I'm not sure if there a significant use case to use set an order or alternative semantics where a subscription is made for each type.

If the request includes an array of subscription types, I think the notification server behaviour can be left undefined, i.e., a variable behaviour, so the server can take any one. (Unless we put stronger semantics on a valid type value but I suggest against this.)

[csarven]

Resolved by #130 in that the subscription request data model requires one type.