Improve java.util.UUID support by optional binary representation

[cowtowncoder]

Although UUID handling can make use of embedded/native byte[], if one is presented, it can not dynamically detect if it should write values as binary.
But with implementation of FasterXML/jackson-core#103 it should be possible to improve things: this would be useful especially for Smile format (and perhaps for Avro as well; and other yet-to-be-written binary-backed codecs).

[cowtowncoder]

Implemented; tested with Smile codec.

[jknack]

@cowtowncoder think this had a side effect, but I can't tell you where exactly is or how to produce it.

Here is the output of a entity that has a attribute: tankId which is an UUID:

{
  "tankId": "96571064-34ea-4d4d-9293-d6ddf2339a5a"
}

Here when we query for a single item the tankId is OK.

Now, see this output:

{
"folder": {
"qualifiedId": "Entry@1286",
"files": [ {
"tankId": "llcQZDTqTU2Sk9bd8jOaWg==",
 ...
}
...

Here we query a folder that has a list of files, do you see the tankId there?

We don't write the object directly, first we convert the object to map, we add a couple more of attributes to the map and then we write the map (not the original object).

Unfortunately, I tried to isolate but I can't reproduce it.

The same code works in <2.3.0

Any help?

Appreciated.

[cowtowncoder]

So, just to make sure I understand: it looks like "write as binary" was accidentally used, even though it should not be?

This is a bug, and should be easy to fix -- will file a separate issue, easier to track progress.

[cowtowncoder]

Re-created as #362.