Consider deprecating the Options module in favour of Taxonomy

Problem/Motivation

Users generally default to using the Options module for pick lists, not realizing that Taxonomy is almost certainly the better choice. A Term Reference field can do everything an Options List can do in a more sustainable way, and has more features.

Some problems with Options lists:

• Items can't easily be deleted.
• Items can't easily be translated.
• Items aren't fieldable.

Personally, I'm getting very tired of spending countless hours writing migration maps, converting list items to taxonomy terms, during major Drupal migrations. They data is usually bad ("dirty data") because list items cannot be managed as effectively as taxonomy terms can. However, users keep setting up fields with it because they don't know about or don't understand the repercussions.

As they're very simple data types and not entities, they're very difficult to work with in any framework sense. The only drawback to using the Taxonomy system instead is performance, as mentioned in #1677052-27: Rename the Options module (which contains the former List module as well):

It's not always the better choice, one advantage is that a list field is far more performant than a taxonomy reference because it doesn't require a separate entity/entities to be loaded when editing/viewing the entity. That's considerable overhead.

But I don't believe this to be much of problem in reality, as most of lists required by users are small (e.g. yes/no choices), or too large to be managed sustainably by Options (in which case Taxonomy would be used anyway). Also, we have much better on-by-default out-of-the-box caching in core nowadays, which should mitigate many performance concerns.

From #1677052-30: Rename the Options module (which contains the former List module as well):

I agree with @Berdir that list/options module might be more performant than taxonomy reference since Drupal doesn't have to load terms from DB, as long as it's not already in memcache. But as a service provider, I almost always prefer to use taxonomy terms than list/options. The problem is that once an option is used, it can not be deleted. If the client still wants to delete an option, we first have to delete it from wherever it has been used. That's a major headache that we want to avoid down the line.

Proposed resolution

1. Deprecate the Options module in Drupal 8.
2. Remove it from Drupal 9.
3. Place it in Contrib for those folks that wish to keep it alive (e.g. for the few cases where performance is an issue).

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD