Add Reader.EmbeddedFiles with a cycle-guarded name-tree walk

[fank]

Why

Inspectors that read PDF attachments (ZUGFeRD/Factur-X invoice XML, etc.) otherwise hand-roll the EmbeddedFiles name-tree walk, and a cyclic or self-referential /Kids graph drives that recursion into a stack overflow — fatal and unrecoverable. (Reproduced here: without the guard, the cyclic test crashes with fatal error: stack overflow.)

What

Reader.EmbeddedFiles() []EmbeddedFile walks the catalog's EmbeddedFiles name tree once and returns the attachments in tree order:

type EmbeddedFile struct {
	Name string // name-tree key, e.g. "factur-x.xml"
	Spec *Dict  // /Filespec dict; its /EF stream holds the bytes
}

The walk is guarded by a visited-set (reference cycles) and a depth cap (inline-nested /Kids), so a hostile tree can neither loop nor overflow the stack. The shape mirrors the existing DocumentInfo() accessor; an ordered slice (not a map) keeps the result deterministic.

Tests

TestEmbeddedFiles (flat), TestEmbeddedFilesNestedKids, TestEmbeddedFilesCyclicKidsTerminates (the cycle that previously overflowed), TestEmbeddedFilesNone. Full suite + go vet pass; gofmt-clean.