Remove superfluous @todos from content moderation

Here is an initial scan of the things I think are candidates to remove.

1. +++ b/core/modules/content_moderation/src/EntityTypeInfo.php
   @@ -158,8 +158,6 @@ protected function addModerationToEntityType(ContentEntityTypeInterface $type) {
   -    // @todo Core forgot to add a direct way to manipulate route_provider, so
   -    // we have to do it the sloppy way for now.
   

   Sounds like something that would get grepped for and fixed if this was ever made a thing. Don't think this is the right place to track this.

2. +++ b/core/modules/content_moderation/src/ParamConverter/EntityRevisionConverter.php
   @@ -28,9 +28,6 @@ class EntityRevisionConverter extends EntityConverter {
   -   *
   -   * @todo: If the parent class is ever cleaned up to use EntityTypeManager
   -   *   instead of Entity manager, this method will also need to be adjusted.
   

   If this ever got cleaned up, the tests would fail.

3. +++ b/core/modules/content_moderation/src/Routing/EntityTypeModerationRouteProvider.php
   @@ -41,7 +41,6 @@ protected function getModerationFormRoute(EntityTypeInterface $entity_type) {
   -      // @todo Come up with a new permission.
   

   Why? I don't see a reason to.

4. +++ b/core/modules/content_moderation/tests/src/Kernel/ViewsDataIntegrationTest.php
   @@ -144,8 +144,6 @@ public function testContentModerationStateBaseJoin() {
   -        // @todo I would have expected that the content_moderation_state default
   -        //   revision is the same one as in the node, but it isn't.
   

   I don't know what this means or if it makes any sense in the context.

My gut feeling is the views integration and test is going to be fixed by #2819477: Views integration incorrectly joins content_moderation_state entities with matching IDs, but different entity types.. The author was probably correct in saying there was something funky going on, because it was indeed broken. I just don't really understand what the comment is saying, hence the (possibly wrong?) assumption it's going to be fine after that issue gets in.

I've looked up the source of the comment, it was authored by @timmillwood in the original issue to bring CM to core. Having thought about it a bit, I think it's referring to the fact that the ContentModerationState entities created to track the moderation state don't mirror the default-ness of the entity revision they are attached to. The logic that neglects this is in \Drupal\content_moderation\EntityOperations::updateOrCreateFromEntity, but I think it's by design.

It believe it's specifically calling out the fact that the default-ness of content revisions isn't mirrored by the ContentModerationState entity:

...expected that the content_moderation_state default revision is the same one as in the node

It's come up as a point of confusion in other issues too, so maybe it should be documented in an issue somewhere, so it can be referred to.

In any case, we can remove it from the patch, I'm hoping to remove the whole relationship in #2894479: Deprecate the Views relationship from moderated content to the "content_moderation_state" entity anyway, so it might be a non issue.