Initialize derived templates with parent images

[joewestcott]

(Based upon #296, please review that one first!)

This allows templates derived from the principal struct (pdf.UseTemplate() or pdf.UseTemplateScaled()) to inherit the parents images list. They'll be available using the same key to facilitate image re-use.

As inheritance happens with the loaded fonts and many other settings, I think images would be expected too. Due to my other PR, this shouldn't increase the final PDF size.

This one however is a ⚠️ breaking change ⚠️. Consider the following scenario...

1. An image is registered in the main pdf pdf.RegisterImageReader("myKey" ...)
2. A new template is derived using pdf.CreateTemplate()
3. An image being registered in the template tpl.RegisterImageReader("myKey" ...)

Due to the new template inheriting images, step 3 will silently fail due to an image already being registered with that key.

It is quite an obscure scenario, but it's best to consider it. I'm not sure how breaking changes are managed in this library (Is that what the v2 branch is for?)

Thanks :)

[jung-kurt]

Thanks for the great feature, @joewestcott. I'll look it over and try to merge it in the next day or so.

It is quite an obscure scenario, but it's best to consider it. I'm not sure how breaking changes are managed in this library

In this case, given the fairly recent addition of templates, I think the right approach is to simply document the limitation. In other cases, an additional API is usually warranted.

(Is that what the v2 branch is for?)

The v2 branch is mostly to make gofpdf dependent only on the standard library. Templates, barcodes, and other contributed code with outside dependencies go into a separate package (gofpdfcontrib). When the dust settles on Go modules my plan is to make gofpdf/v2 the default branch.