feat: read the retained data of proxy entities and objects

[WallanceLee]

Description

readCommonProxyData stopped right before the retained data of the original object:

//Common:
//Databits X databits, however many there are to the handles

//TODO: Investigate how to read the data in proxies, it can contain data, strings and handles

That section is the only place where a custom object survives once it has been saved as a proxy, so
while it stays unread the payload of any custom object is inaccessible to a consumer of the file.

The section has no length of its own: it extends from the end of the proxy fields up to the start of
the handle section. The reader already computes that offset when it splits the object stream for
R2010 and later:

ulong handleSectionOffset = (ulong)this._crcReader.PositionInBits() + sizeInBits - handleSize;

So the value is kept in a field and the remaining bits are read as the data.

ProxyObject already exposed a Data stream, filled from group 311 in DXF. ProxyEntity had no
such member, so it gets one with the same shape and the same DXF code.

Before R2010 the handle section offset is not encoded in the file, sections without a length cannot
be delimited, and the data is left unset exactly as it was before.

Tasks done in this PR

• Keep the handle section offset that is already computed while splitting the object stream.
• Read the retained data of a proxy from the end of the proxy fields up to the handle section.
• Added ProxyEntity.Data (group 311), matching the member ProxyObject already has.

Related Issues / Pull Requests

• feat: read Tianzheng TDBXDATAMAP property blocks #1275 decodes the Tianzheng property block; this PR is what makes that payload readable on the
  DWG path. Independent changes, but they fit together.
• fix: add AEC_MODI and AEC_SYMB_SECTION as ProxyEntity in readUnlisted… #1148 — this is the part of that problem worth keeping. The PR there routed objects that are
  stored natively through the proxy readers, which consumes the wrong bits; the retained data of
  the objects that really are proxies was never read instead.

Notes for reviewer

Verification. I compared the reader with and without the change over 21 DWG files
(1,607,215 entities in total), because consuming the section advances the object reader and could
have disturbed the reads that follow:

	before	after
proxy data decoded	0 bytes	2,358 bytes
entities read	1,607,215	1,607,215
files differing in entity count or a fingerprint of entity types and handles	—	0

Two files in that set contain proxies (A3____.dwg: 2 proxies, 58 bytes; a 23-proxy drawing:
2,300 bytes); the other 19 have none and are unchanged, which is the expected no-op case.

No regression test included. A test needs a DWG that actually contains a proxy entity, and the
ones I have are 579 KB and 643 KB, larger than I wanted to add to samples/ without asking. I am
happy to add one if you want the test, or to use a file you prefer — please say which.

Scope. This only exposes the bytes. Interpreting them is what tells the two PRs apart: reading
the payload is now possible, what a given application stores in it is a separate question.

Out of scope, but worth knowing. The section is measured in bits and I round up to whole bytes,
so the last byte can carry up to 7 padding bits that belong to the handle section. For a caller that
parses the payload from the start this makes no difference; a caller that walks it from the end
would need the exact bit length, which is why the offset is kept in a field rather than discarded.