The report controller isn't plugin-agnostic

Problem/Motivation

The code in the report controller (FieldPermissionsController) still has a bunch of assumptions around table headings etc, based on the custom access plugin. Similarly, the permissions service still has some of the methods that should be in the custom access plugin.

From @kevin.dutra:

There's some disconnect in the report, part of which you've already acknowledged in the comment for FieldPermissionsServiceInterface::getList(). Let's say I add a new LlamaAccess plugin that provides permission llama power for [field]. This is the only field access type I have in use and it's only used on the Body field. I look at the report and the header lists 5 permissions that aren't actually in use anywhere. When I look at the row for the Body field, the information for my llama permission is slotted under the "Create field" column, which is misleading.
Rather than designating one column for each permission, which proves to be problematic, what if we just had a single "Permissions" column where we provide a list of the permissions there? Not beautiful, but it would at least accommodate the varying nature of the permissions that plugins may provide. I think at that point we can abstract the getList($field_name) sort of functionality to a new method on the CustomPermissionsInterface.

Proposed resolution

Clean up the code at a minimum. Potentially refactor the column headings.

Remaining tasks

User interface changes

API changes

Data model changes