Add support for feaurelayers without geometries

[steff-o]

Is your feature request related to a problem? Please describe.
If a table does not have a geometry, it is not possible to add or delete or edit attributes unless they are configured as related tables. The main problem is that there is no way to select a feature for editing without clicking it in the map, and possibly some code that tries to use the geometry without checking if there really is one. This would be especially useful for administering tables that are used as related tables using a many-to-one relation.

Describe the solution you'd like
It should be possible to add new table rows, delete table rows and edit attributes for a row even if the row lacks geometry. Not sure how it would be done. The best solution would be a table view (similar to ArcMap) for tables without geometry and a sync between table view and map for features with geometry, but I could also settle for some api-functions on the editor in order for external code to:

1. Inject a new feature to a layer
2. Open attribute editor for a feature
3. Delete a feature

Another possible solution would be using the InfoWindow as base for controlling these tables, which has sort of a link between table view and map and could be augmented with buttons for each feature to open a selected feature in the attribute editor and delete objects. On each layer tab a add button could be added. In that case the only thing missing is how to open a table. Most intuitive way would be right click in the legend. If the editor could start editing a selection from InfoWindow ( or more generally FeatureInfo) instead of requiring using the Select map interaction (soon in a feature request), a button could be avoided and delete could be moved to the attribute editor.

Well, as you see, I'm not sure where this is going so the first step would probably adding api functions. Even if the GUI is implemented in the core I think it would be nice with an Api as the editor component is implemented as a black box that only communicates using obscure DOM events at document level, probably only intended to be used by the editor menu.

Describe alternatives you've considered
Throwing some obscure DOM events at document level to affect the editor to perform my actions, but that will crash on some geometry handling and is a very ugly solution.

Edit: unless #1614 is implemented one must also grab the Select interaction from the map and modify the selection in order to edit attributes.

Adding the table as a related table to a layer with one dummyfeature as parent, but that quickly becomes ugly as the table view will be the attribute editor for the parent, and that would look messy if the table has more than 10 rows or so. And also, is not very intuitive for the user.

Implementing everything out of band using a separate server component accessing the same table, but that would not use the benefits of using WFS as service layer, using the same access control etc.

Additional context
Add any other context or screenshots about the feature request here.

[steff-o]

Superseded by #1615 and #1616