Unconditionally overwrite `meta.creator` on writing

[madig]

Since the creator value is meant to represent the writer of the UFO, norad should always write down itself there. I don#t think it is necessary anymore to refuse writing out UFOs not created in norad.

Annoying edge case to think about: save() should not modify self, so it would ignore what the user put into meta. This is slightly iffy.

[cmyr]

good call, I would like to remove 'not created here' from this release.

[alerque]

I agree this should be the default, but disagree about "unconditionally". I would like to enable using this library to twiddle things and normalize files where the user may be using another library to actually write the files themselves. The most obvious direction no normalize in is stripping out this meta data entirely, but another way of handling it should be to not mess with the value from what was read in. There should be a conditional flag of some kind about whether or not to update meta.creator. It should default to true, but there should be a way to use the library without getting into a source diff tug of war with some other app in a pipeline.

[madig]

Hm. Creator is supposed to be "The application or library that created the UFO", so we have no choice in this matter 💀

[alerque]

Pshaw. Yet another thing about normalization I should take upstream to the UFO spec. I think it is wrong to have this as a required field.

In the mean time what if I want to use this library in my application and write the value of my application name. That would be another use case for this being something the library allows options for. The application name is arguably quite a bit more revealing/useful than the library used by the application (as the latter can be derived anyway.

[cmyr]

I am in favour of making norad as generally useful as possible, within reason, and exposing an option to let the user override or ignore this field doesn't feel unreasonable.

That said, I'm really not sure where this option should live? I could possibly imagine some set of config options that can be set on a Font object, but this is slightly tricky; for instance if any of these options influenced behaviour when reading a file from disk, we would want to provide it to the open method. I guess this could work sort of like DataRequest?

If this is mostly just about options for serialization, we could also split it out and have a save_with_options method. I could imagine this also being somewhere that the user could specify whitespace, etc?

[cmyr]

I've gone with just unilaterally writing us out as the creator, for now. I'm open to ideas about customizing this behaviour in the future, maybe when we also expose other options like customizing whitespace?