Add support for "Interest" endpoints, deprecate "Interest label" endpoints

I have the following remarks when reviewing:

• The method \Drupal\flexmail\api\value\Value::validateFieldsPresent doesn't seem to be used at the moment.
• It's also a bit strange that helper static methods are placed in an abstract (base) class. Why is that abstract class needed, shouldn't the helper logic be better off in a Utility class?
• Secondary, Maybe ValueBase is a better name, if a base class is deemed useful to add base logic to in a later phase?
• If there is an interface \Drupal\flexmail\api\value\ValueInterface, I'd expect the base class to implement that interface, since based on the name it seems to be something uniform for all value classes.

The logic looks good in general. Could you check the comments above?

Next to that, is there a blog post or more information that can be shared? Since we'll need a follow-up issue to update the flexmail_webform submodule, since there is logic there that depends on the deprecated methods.

Thanks for the updates, some feedback again :)

• Why not add sameValueTypeAs and maybe even getId in the interface, so you can use the interface as typehint where appropriate? Or doesn't that make sense?
• You use ValueAbstract::sameValueTypeAs() in the docblock for \Drupal\flexmail\api\value\ValueInterface::sameValueAs, which should be changed to ValueBase::, or if the comment above makes sense and you agree, to ValueInterface::
• It makes sense about keeping the static classes in there, it just looked a bit weird to have only static classes in there, now it just looks more logical in my mind, since there's other regular methods in there.
• In the constructors for some classes a comment says "The constructor is protected", maybe that should be private instead of protected, since the method is private?
• Keeping \Drupal\flexmail\api\value\Value::validateFieldsPresent in there is ok for me, it was just weird to add a method that isn't used. Especially since that's a method that imo should/could be used in the basic API layer. If you feel it's an added value, feel free to add it back in.

Looks good to me, I'll give Matthijs a chance to look at it, if he doesn't have time, I'll merge. ping me if it becomes urgent!

Marking as needs work based on the feedback!

Replied in the threads. I would suggest to fix these last 3 issues, then it's RTBC.

We only need a better solution for the getId method, having an empty id method that should never be used for some valueobjects doesn't seem right. Maybe we can have ValueObjectBase and ValueCollectionBase with a common ValueBase? Or using traits as suggested before?

Merged, thanks for the contribution!