208 better reporting of failed exported objects

[flipmcf]

This adds a new form field on @@export_content "write_errors" which turns on a list of unexported paths at the end of a json export.

When 'write_errors' is set to a true value, the export appends the list like so:

[{
    "@id": "http://localhost:8081/RFA/english/item1",
    "@type": "news_item",
    "UID": "34b9faa0dbe648b6826174abc4ff85c1",
    ... <snip>
},
{
    "@id": "http://localhost:8081/RFA/english/item2",
    "@type": "news_item",
    "UID": "34b9faa0dbe648b6826174abc4ff85c2",
    ... <snip>
},{
    "@id": "http://localhost:8081/RFA/english/item3",
    "@type": "news_item",
    "UID": "34b9faa0dbe648b6826174abc4ff85c3",
    ... <snip>
},{
    "unexported_paths": [
        {
            "path": "http://localhost:8081/RFA/english/news/story-slideshow-05232023120021.html",
            "message": "Error exporting http://localhost:8081/RFA/english/news/story-slideshow-05232023120021.html"
        }
    ]
}]

Additionally, ~some log messages were converted to 'f' strings to "leave it better than you found it" and~ error logs now show number of errors or 'skipped objects' during export:

2023-06-08 13:55:06,216 INFO    [collective.exportimport.export_content:237][waitress-0] Exported 50 ['Image', 'Kaltura Video', 'press release', 'raw html', 'section', 'Slideshow', 'story', 'subsite', 'testipublication', 'chair'] with 1 errors

[flipmcf]

failing the py27 tests.... I guess the whole "hey, these can be f-strings!" idea wasn't so good after all.

[flipmcf]

Thank you!

I'm not satisfied because it (probably) generates a export that is not importable back into plone - if errors occur. I haven't tested importing back into plone if the error dictionary with "unexported_paths" exists at the end.

But maybe we like making exports with errors fail on import - because it stops the import and the user must face the fact that some objects didn't export.