Add experimental coref docs

[polm]

Description

This PR includes just the docs written in #7264, which now cover the components in https://github.com/explosion/spacy-experimental/pull/17. #7264 can be closed in favor of this PR.

This should not be merged before https://github.com/explosion/spacy-experimental/pull/17.

One question is what version should be listed for the introduction of these components; currently it's 3.4.

(A few unrelated lines in the architecture docs were modified by prettier.)

Types of change

docs update

Checklist

• [x] I confirm that I have the right to submit this contribution under the project's MIT license.
• [ ] I ran the tests, and all new and existing tests passed.
• [x] My changes don't require a change to the documentation, or if they do, I've added all required information.

[svlandeg]

One question is what version should be listed for the introduction of these components; currently it's 3.4.

It shouldn't list any spaCy version yet, until we actually port it over from experimental.

[adrianeboyd]

Are we sure we want to put this in the main docs? There's no explanation of spacy-experimental or tags related to this?

[adrianeboyd]

I think it would be okay to redefine the experimental tag to mean spacy-experimental, but we should then keep it that way in the future rather than trying to use it for both uses.

[polm]

I think it would be okay to redefine the experimental tag to mean spacy-experimental, but we should then keep it that way in the future rather than trying to use it for both uses.

In that case what should we do for features like rehearsal, that can't be split out into spacy-experimental?

[adrianeboyd]

That is a good point. I think having two separate experimental and spacy-experimental tags is going to be too confusing.

[polm]

How about we:

1. use experimental for both spacy-experimental and experimental features in core
2. make a point of using warning infoboxes or other techniques to signpost things in spacy-experimental?

I think the point of the experimental tag is to indicate that APIs may be unstable or it may have seen less real-world use, and that's true of features in core or spacy-experimental, so sharing the tag makes sense.

While it is true that it can be confusing if someone misses the note that an experimental feature is in a separate package, I think that's the kind of temporary confusion that's easily fixed, rather than something more serious like breaking an existing application. If we're diligent about signposting things that require the extra library, then I think the small chance of confusion is a fair tradeoff for the benefit of having the docs all in one place with consistent formatting (and being searchable too).

[polm]

I'll put this in draft state until https://github.com/explosion/spacy-experimental/pull/17 has been merged.

[polm]

Test failure here is due to https://github.com/python/mypy/issues/13627. Since this PR contains no code, only docs, it should be safe to ignore.

[polm]

It looks like this hadn't actually been updated to make sure the sample code worked since the implementation moved to spacy-experimental, but that should be taken care of now.