getDetails() returning single element arrays instead of strings

In the sample PDF for #391 /samples/bugs/Issue391.pdf the results of getDetails() returns a set of values that are single element arrays instead of strings:

Expected:

array(6) {
  ["Title"]=>
  string(49) "Microsoft Word - GVTW70SPAH1R0_20101210_REV_A.doc"
  ["Author"]=>
  string(8) "aronzhao"
  ["Producer"]=>
  string(33) "Mac OS X 10.7.2 Quartz PDFContext"
  ["Creator"]=>
  string(26) "PScript5.dll Version 5.2.2"
  ["CreationDate"]=>
  string(25) "2011-12-28T21:12:01+00:00"
  ["ModDate"]=>
  string(25) "2011-12-28T21:12:01+00:00"
}

Actual:

array(6) {
  ["Title"]=>
  array(1) {
    [0]=>
    string(49) "Microsoft Word - GVTW70SPAH1R0_20101210_REV_A.doc"
  }
  ["Author"]=>
  array(1) {
    [0]=>
    string(8) "aronzhao"
  }
  ["Producer"]=>
  array(1) {
    [0]=>
    string(33) "Mac OS X 10.7.2 Quartz PDFContext"
  }
  ["Creator"]=>
  array(1) {
    [0]=>
    string(26) "PScript5.dll Version 5.2.2"
  }
  ["CreationDate"]=>
  array(1) {
    [0]=>
    string(25) "2011-12-28T21:12:01+00:00"
  }
  ["ModDate"]=>
  array(1) {
    [0]=>
    string(25) "2011-12-28T21:12:01+00:00"
  }
}

I knew arrays of XMP details values were possible, but not so for the regular details. I'll have to look at the PDF reference again, but they are probably allowed and PdfParser is parsing them properly.

My PR #606 automatically converts any XMP property that's a single element array into the value of that single element. Should we do that in this case for the regular details?

Start with samples/bugs/Issue391.pdf and the getDetails() entry point, then review the PDF reference and PR #606 for how single-element XMP arrays are handled. Confirm whether regular detail arrays are valid, and define done as consistent handling of scalar values while preserving legitimate multi-element values, with regression coverage for this sample.