Inherited properties are not folded into the entity that inherits them

[peopleworks]

Found reviewing #9. Filing it rather than growing that PR, since it is older than the change and true independently of it.

What happens

An entity that inherits from a class in the same project is reported with only the properties it declares itself. Measured against #9's DeepXpoSolution fixture:

NamedBaseObject   declares  Name                          reported: 1 property
Order             declares  Number    inherits  Name      reported: 1 property
PriorityOrder     declares  Rank      inherits  Name, Number   reported: 1 of 3

PriorityOrder.Name and PriorityOrder.Number exist, are persisted, appear in views, and are readable from any code an agent writes. They are in no section of the generated documentation.

Why it matters more now than it did

This was always true and nobody could meet it. Before the DbSet roster (0.12.1) and the base walk (#9), a class deriving from a project's own base was not extracted at all — so the properties were missing along with the class, and the whole thing was invisible.

Making those classes visible converts a silent omission into a stated one. PriorityOrder now appears under a heading that presents this application's entities, with two thirds of its columns absent, and an agent told the lists are complete has no way to know. Under the project's own rule that is the bad shape: not a gap, an inventory that promises to be whole and is not.

At scale it is the shared base that hurts. An application on an AuditedObject loses whatever that base holds from every entity, which is normally the audit fields — ChangedBy, ChangedOn, the ones an agent most needs to know it must not set by hand.

What it should do

Fold each ancestor's properties into the entity, in declaration order from the root down, so the inherited ones read the way they do in the class. The base walk in #9 already computes the chain and resolves each hop through the deriving file's scope, so the ancestry is known by the time entities are built — this is about what ExtractEntity is given, not about finding anything new.

Two things to decide while doing it:

1. Whether an inherited property is marked as such. Knowing ChangedOn comes from AuditedObject and not from Order is worth something to a reader, and costs a field.
2. What happens to the abstract base itself (the other half of [gap] XPO entities two hops from BaseObject are dropped, and their abstract base is reported instead #6, also unaddressed). If its properties are folded into every descendant, listing it as a business entity of its own becomes more misleading, not less — the same columns then appear twice under two headings, one of which is not a table.

Related: #6, #9.