Clarify distinction between SPEC and implementation

[tupui]

There is a lot of discussions in projects around what it means to endorse vs what is written on each SPEC.

To help clarify things, I propose that we create an optional section on the SPECs to show our suggestion of implementation. E.g. for SPEC0 and SPEC4, we could add the section Suggested implementation and describe what we currently have with the calendar and lazy loading package.

[stefanv]

Thanks for the suggestion, Pamphile. Can you expand a bit on what you think this section would contain? In my mind, the SPEC was the suggestion, but perhaps there's a further clarification needed.

I think we also agreed to make it more obvious what endorsement means, by adding a hover (and perhaps icon) to the SPEC list.

[jarrodmillman]

The SPECs already have two sections where this information should go:

### Core Project Endorsement

<!--
Discuss what it means for a core project to endorse this SPEC.
-->

### Ecosystem Adoption

<!--
Discuss what it means for a project to adopt this SPEC.
-->

We haven't completed these sections for the existing SPECs. It would be great if you (or someone else) wanted to make a PR to update the existing SPECs with this information. We should also discuss this at the next SPEC committee call, which we will send out a poll to schedule later today.

[tupui]

Yep, I am all for making a call 😃

I had a look and seems like these sections are not really filled for the current SPECs (0, 1, 4).

I think these sections are good and should be moved to the top, after the SPEC itself. What I would move to a specific section, would be the "implementation" part. This should make it clear that this is just an example.

Basically I would propose the following structure:

### Description

<!--
The SPEC itself.
-->

### Core Project Endorsement

<!--
Discuss what it means for a core project to endorse this SPEC.
-->

### Ecosystem Adoption

<!--
Discuss what it means for a project to adopt this SPEC.
-->

### Suggested implementation

<!--
An generic implementation which follows the SPEC
-->

Basically with recent discussions we need to be clearer on what is "required" and what is optional. E.g. for SPEC0 basically what we want (since we said NEP29 is valid) is that project have a deprecation policy for deps/Python. Up to us to add more constrains such as minimal support of e.g. 2 years if you want to be "compliant". This information would go into the Core Project Endorsement section and Ecosystem Adoption would list the NEP29 as NumPy's implementation.