Fix Form fields with unexistant fonts with '/' in font name

It may happen that a Form field's DA string contains a font name that is non-existant, in that case Poppler creates a default Helvetica font to use instead, that font is created with the same name as the one non-existant, problem arises when that font name has a / char which is a pdf delimiter char and must be escape/unescape when reading/writing it to pdf, which Poppler does, but Poppler failed at parsing the following awful case of Tf command which tries to refer such font name with /:

BT
/ /Helvetica 12 Tf
ET

Poppler interpreted previous Tf command as having two Name parameters, the first one containing empty string and the second one containing Helvetica where we need just one Name parameter and that to be /Helvetica so that such font can be looked up correctly.

Apart from that Tf command fix, we also improved function Form::ensureFontsForAllCharacters() so that it also looks for fonts in the Resources (if present) of the field's widget annotation default N appearance stream AP i.e. Field -> AnnotWidget -> AP -> N -> Resources because sometimes (as is the case of #1529 pdf file) the font mentioned in DefaultAppearance DA string is only present in those Resources. This allows that entering non-latin text also works for such text fields.

Fixes #1529