Clean up and complete text format config entity conversion

Related: #1871586: Clean up architecture once formats are ConfigEntities and filters are plugins

The blocker went in a long time ago.

Many of the subtasks are novice-level, so tagging as such.

Some of this is covered by the linked issue.

8: cleanup-text-format-filter-module-1881664-8.patch queued for re-testing.

I have looked at this patch (because filter) and it doesn't have a security hole -- it's hard to imagine how it could have one -- otherwise it's also good.

It looks like filter.module changed enough to prevent #8 from applying cleanly. Rerolled & tested locally.

I'm here at DrupalCon Amsterdam and I'm going to review the patch.

The patch #12 applies cleanly.

The patch did not apply cleanly for me, because the filter module has probably been changed between the initial posting by @thechangeg and the current state of the D8 beta.

To resolve, I've rerolled a new patch

I have cleanly applied patch #16 and implemented subtasks 3 and 4.

I have created an interdiff and implemented subtasks 1 and 2.

The patch #18 applies cleanly.

I've reverted the additions made by @k0teg in #17: they crashed the whole filter format system.

I think we first have to look at references made elsewhere to the base properties FilterFormat::format and FilterFormat::name before being able to safely change the attributes. I'm also afraid #17 breaks the text module, which depends on the filter module.

@sun: I'm not sure if the comments in the original issue summary still apply, because the issue is actually quite old. So here are some concerns I have. It would be great if you could have a look at those, so I can continue my work:

- The first two remarks were (easily) fixed in #21.
- About the third and fourth comment: aren't the id() and label() methods around to have consistency to the 'outside world'? To clarify: I've changed the code to fix the first two remarks, so outside of the class, the id() and label() methods are used instead of refering directly to the properties on the class (->name and ->format). But inside the class, isn't it ok (and even encouraged) to use more descriptive properties instead of the generalized ones? So isn't using ->format and ->name properties (and then having an id() and label() method returning those properties) ok?
- Could you update the seventh subtask? What still needs to be done here?
- About the 11th subtask: I couldn't find any references to $filter->title anymore. Deprecrated issue?
- Could you elaborate on 12 & 13 & 14?

Code changes for a task go to 8.2.x.

Patch doesn't apply.

I faced some conflicts while re-rolling , i fixed those conflicts and rerolled the patch and i found out that everything which was in the patch is already fixed in 8.2.x

Sorry mistakenly changed the status. that comment for the previous patch only

rerolled

Removing the reroll tag as that's been taken care of.

The patch in #30 only adds a blank line.

As #28 points out, all the substantive changes seem to be in core already. So I'm marking this as closed (works as designed).