SQL VIEWs as entities

# Motivation

While the word 'view' occurs only once in the JPA 2.2 spec and not in the context of an SQL view, the JPA standard does not explicitely rule out entities that are based on database views. I simply only mentions tables as basis for entities.

However, from a query perspective views have a lot in common with tables (they can be used in place of them), and therefore may be easily mapped to JPA entities like ordinary tables.
Various sources on the internet suggest that technique. [1],[2]

There are a couple of (more or less obvious) limitations with views-as-entities:
* Views have no primary key,
* The JPA provider does not see links between views and tables that they are based upon, producing potential update anomalies and caching issues if the view of entity V is based on the table of entity T. Updates to T may not be reflected in V. If V is cached, it needs to be refreshed explicitely
* Updates or inserts are limited or even impossible (databases often support this under certain circumstances, but it's database specific and not reasonable detectable by gentity)
* Element collections or entity associations are hard because in general views have no concept of foreign keys.

# Proposal

Mapping views to entities should be a conscious decision of the person designing the mapping. Therefore, it appears advisable to not generate views-as-entities by default; rather, such entities should be requested explicitely via customization (at least until we have more experience with the scheme).

To make a view into an entity, the new `` element is added. It functions in many ways similar to ``, but only supports the `` subelement (collections and associations remain unsupported for now; might be extended later).

# Notes

It was initially considered to mark all fields in a view-as-entity as `insertable=false` or `updatable=false` (see #31). However, this would limit views too much, as there are views that allow updating. The main concern about views in general is that they're very database specific (their creation as well as updating/inserting). For this reason, we don't create them by default, but require the user to explicitely request mapping a view in the customization file.

---
[1] [https://vladmihalcea.com/map-jpa-entity-to-view-or-sql-query-with-hibernate/](https://vladmihalcea.com/map-jpa-entity-to-view-or-sql-query-with-hibernate/)
[2] [https://en.wikibooks.org/wiki/Java_Persistence/Advanced_Topics#Views](https://en.wikibooks.org/wiki/Java_Persistence/Advanced_Topics#Views)

Start by locating the customization-file handling and the existing mapping path. Trace how elements are parsed and turned into generated entities, then define the corresponding behavior, including the restriction against collections and associations. Done means views are opt-in and generate field-only entities without changing default generation.

Written by the indexing model from the issue text.