PPD option JCLToPDFInterpreter's value is not decoded, breaks printing for PDF+PJL PPDs #24

Describe the bug
If PPD uses PDF as output format and uses PJL, printing does not work for printers installed with such PPD - output file is created, but it is broken due:

19 @PJL SET USERID="User1"
-->>> 20 @PJL ENTER LANGUAGE = PDF<0A>%PDF-1.3
 21 %¿÷¢þ

(There no new line between the last PJL command and start of PDF)

To Reproduce
out.pdf.txt
log.txt
ricoh-bad.ppd.txt

$ PPD=ricoh-bad.ppd CONTENT_TYPE=text/plain FINAL_CONTENT_TYPE=application/vnd.cups-pdf /usr/lib/cups/filter/universal 1 root '' 1 '' /etc/fstab > out.pdf
$ netcat < out.pdf
(the file is not printed)

Expected behavior
Printed file

System Information:

• OS: Any OS with libppd - Fedora 38, Ubuntu 23.04
• libppd-2.0-rc2

Additional context
The discrepancy in the output file happens because the value of the option JCLToPDFInterpreter is not decoded when reading it from PPD file - decoding is hidden only for CUPS 3.X:

ppd/ppd.c:
 887 #if HAVE_CUPS_3_X
 888     else if (!strcmp(keyword, "JCLToPDFInterpreter"))
 889     {
 890       ppd->jcl_pdf = strdup(string);
 891       ppd_decode(ppd->jcl_pdf);         // Decode quoted string
 892     }
 893 #endif

For CUPS 2.X, the option and value stays among PPD attributes value, where it is not decoded.

I can see two ways how to fix this:

1. remove the ifdefs related to this value - I'm not entirely sure why only this part should be different for CUPS 3.x/2.x,

2. make ppd_decode() extern, and call it in ppdEmitJCLPDF() when we have CUPS 2.x.

@tillkamppeter which one do you prefer? (I have patch ready for the second for the record)