Fully support custom entity type extending paragraph

Problem/Motivation

In the past I always thought I need to choose between paragraphs vs inline entity form + custom entity types.

Today I learned that I can create custom entity types that extend Drupal\paragraphs\Entity\Paragraph, or that implement Drupal\paragraphs\ParagraphInterface. This is thanks to the widget relying on instanceof checks instead of hard-coding the entity type. Kudos for that!

The approach combines the benefits of both worlds:

• Use the widgets from paragraphs, which provide better UX than inline entity form.
• Have separate dedicated entity types, instead of an endless list of paragraph types.
  There are situations where this is preferable.

However, there are currently some concerns with this approach:

• There are (afaik) no tests that cover this possibility, and I did not see it documented anywhere.
  This raises the fear that this possibility might break in a future version of paragraphs, or that there are some limitations I have not found yet.
• The ParagraphsInterface might contain more methods than are needed to integrate with the widgets and formatters. At least the methods marked as legacy.
• There is no abstract base class or trait, there is only the Paragraph class itself to extend.
  This means any future changes to this class will impact all inheritors.
• I think the interface and a lot of paragraphs module assume that the entity type has bundles. There are methods ParagraphInterface::getType() and ParagraphInterface::getParagraphType().

Steps to reproduce

Proposed resolution

The first goal of this issue is to put this possibility on the radar of the maintainers.

The second goal or wish is to see an official commitment in the form of tests and documentation, that this is possible and will be supported in the future.

The third goal is to improve support and flexibility.
E.g. support entities that don't have bundles.

(I might add more information to this issue, but atm I am still in an exploration phase.)

Changes, step 1
Always use interface instead of class.
Don't rely on 'paragraph' string literal for the entity type id.
Don't rely on 'paragraphs_type' string literal as the bundle entity type id.
Support bundle-less entity types.
Support entity types without icon and without behavior plugins.

Changes, Step 2
Create a weaker interface and a base class with only the methods needed for the widget.
Use opt-in interfaces and traits for special functionality like the behavior plugins.

Remaining tasks

User interface changes

API changes

Data model changes