Add logic to support sending structured entries to the journald log

[sohankunkerkar]

Fixes #43 and enable us to use that logic in the afterburn repo to solve(coreos/afterburn#395)

[lucab]

A bunch of high-level things:

• please do a cargo fmt pass on this PR
• the CI here is currently stuck (I have a support ticket ongoing with Travis), so you'll manually have to run the tests for the moment
• I think that @jlebon was looking for a more generic method signature in logging: implement sending structured entries #43

[jlebon]

This is OK, though... if we want to truly match the API semantics, the value could technically just be bytes. UTF-8 is recommended, but binary is fully supported. So this could even be AsRef<[u8]>.

[lucab]

It looks like both the C and the Go API handle strings, and even binary stuff like MESSAGE_ID is hex-encoded. I think that handling strings here is ok.

[jlebon]

The protocol itself allows for any arbitrary binary data. systemd-coredump for example can be configured to store full coredump in the journal (which is why journal messages have a crazy limit like 768M). And in rpm-ostree, I almost made use of binary values as well in the journal when implementing coreos/rpm-ostree#1813.

[jlebon]

(To be clear, this WFM as is too, just wanted to flag we weren't exposing the full capabilities of the API. We can always add a separate API later on if the need arises.)

[lucab]

Yeah, it is starting to get tricky. The C API has a further split between _send and _sendv for the string-vs-bytes topic.
I'd say we keep this signature for the moment and then iterate on a lower level helper on the side. I think in that case having split priority/message does not make sense either.

[lucab]

Travis reporting is still KO. Manually triggered a build, status is green: https://travis-ci.org/github/lucab/libsystemd-rs/builds/677601755. Merging.