file.serialize state: fix corruption when using msgpack serializer

[terminalmage]

The file.serialize state adds a newline to the end of the serialized contents before writing them to disk. This works fine with some serializers, but not so well with others. MacOS plist files are invalid with a trailing newline, so a recent release added a check for that. But that still leaves msgpack, which is also corrupted by the addition of a trailing newline (resulting in a "received extra bytes" error when one attempts to unpack the file).

This changeset keeps the state from adding the newline to the end of the file when using the msgpack serializer. In doing so, it simplifies the logic that determines whether or not to add the newline. It makes the assumption that if the serialized contents are a bytestring (as in the plist and msgpack serializers), a newline should not be added, as the results are likely in a binary format that will not work well with unexpected bytes added.

Additionally, it introduces a new argument to the state: serializer. When the file.serialize state was added to Salt nearly 7 years ago, it for some reason was written to use formatter to specify which serializer to use. Which is fine, in its own quirky way, but later on the serializer_opts and deserializer_opts arguments were added to allow the user to pass through additional options to the serializer. And this leaves you with serializer_opts/deserializer_opts, and formatter instead of serializer. It's weird and asymmetric. So this changeset also adds serializer (updating docs to prefer this usage), while maintaining backwards compatibility with formatter.