Split SAI in separate (sub)specs

Start by reading the SAI specification sections 5 and 6, then review its Access Needs and Access Authorizations sections. Compare the proposal with the linked WebID Profile and type-index issues. Done would require agreement on the separation of concerns and the resulting specification boundaries before implementation begins.

In relation to https://github.com/solid/webid-profile/issues/66, I would like to argue here that the SAI specification, just like the WebID-Profile spec, tries to do to many things at once. This results in each of these things being more tightly bound to others than necessary, which violates the principle of orthogonality, and thus complicates expandibility and compatibility.

Lots of powerful mechanisms on the Web work because of relatively small specs being able to work together. I would therefore like to propose we do the same, and split this document according to the specific needs that it tries to address, in order to tackle them separately, informed by current practices, and in cooperation/merging with other drafts tackling the same problems.

I retake two of the possible separation of concerns I suggested in https://github.com/solid/webid-profile/issues/66, and add a third:

1. A primary document should focus on authorization and application registrations, as suggested in https://github.com/solid/webid-profile/issues/62 [and formulated under SAI section 5]. The goal there should be to provide apps with a simple step from the identity of a user to a separate (sub)sphere where information can be found pertaining to the user's relation to that specific app. In other words: the application registration becomes the Profile extended with what that specific app needs and is allowed to.

2. Following the definitely justified separation of type indexes, and the issues raised in https://github.com/solid/webid-profile/issues/65, a central discussion is remains how agents can discover where to access data. [Since SAI data registrations, as specified in section 6] are almost identical [to type indexes], [p]ooling the insights of both would prove much more valuable. Building this pooled insight on top of [1] is a must i.m.o.

3. The sections on Access Needs and Access Authorizations could form one or two separate specs, (abstractly) building on [1] and [2]. This might require some changes, but keeps open the possibility of extending or replacing any of the interoperability parts in a much more flexible way.