Uruguayan eID: check the decoding notes against AGESIC's documentation

[carlosplanchon]

Cross-checks the decoding section in OpenSC#34 against AGESIC's official technical
documentation and against a v4 card, and records where the two disagree.

The TLV skeleton holds up exactly as you wrote it: 5F 01 for 7001 with a
fixed length of 9, 1F 01 to 1F 06 for 7002, 3F 01 with a long-form
length for 7004, 7F 01 for 700B, and the three length forms with the same
offsets. The document even carries the same worked example for the portrait,
T=0x3F01 L=0x8223FE.

One warning about the source: the TLV tables in the PDF are images, so
pdftotext returns blank gaps where they should be. They have to be rendered as
images and read. That is probably why nobody had cross-checked them before.

What changed:

• UTF-8. The document states every value is ASCII. Cards store UTF-8, so the
  page now presents this as correcting the specification rather than
  contradicting it silently. Confirmed on a card, with bytes above 0x7F that
  decode as UTF-8.
• 1F 08 is the date of issue, four bytes of packed BCD in DD MM YY YY
  order. The document mentions a date of issue exactly once, to say it is the
  one value that is not ASCII, and never says which tag holds it. This is that
  tag. Verified by decoding it and comparing against the printed card.
• A warning for 1F 08. BCD bytes stay below 0x80, so scanning for high
  bytes reports the field as ASCII and decoding it as text succeeds and returns
  punctuation instead of raising. A card issued this century even carries a
  literal 0x20 for the 20 of the year, which reads as a space. This is worth
  stating because it is an easy trap to fall into.
• Documented versus observed. The document only specifies 1F 01 to 1F 06
  and fixes two lengths, 1F 04 at 3 and 1F 05 at 8. The rows beyond that are
  now marked as read from cards, so a reviewer who opens the PDF does not think
  the page invented them.
• The surname warning has a source now. The document names 1F 01
  PrimerApellido and 1F 02 SegundoApellido, which is what makes the warning
  worth stating. On the card I read, both surnames sit in 1F 01 with 1F 02
  zero-length, so the case you describe is real.
• 1F 0A stays unidentified, zero-length on the cards read so far. AGESIC's
  reference code models one field no tag accounts for, observations, which
  would fit, marked as the guess it is.
• The MRZ layouts are marked as coming from ICAO 9303, since the document
  does not state the length. The dump on the page is a TD1 value.
• 711D. Added a note that these objects are unverified data. AGESIC's own
  reference code reports the data as unsigned when the SOD is missing, and it is
  missing on earlier batches, which is why the driver does not expose it.
• Sources added to the resources list, plus the Path column renamed to
  EF, since it held file IDs and not the paths printed in the dump above it.

Everything here is either in the linked documentation or was measured on a card.
No personal data was used, only field structure, lengths and encodings.