First pass at basic utilities and interface types

[gcarcassi]

This pull request contains:
epics-util: support of unsigned integer wrapper class
epics-util: support for unsigned/signed integer conversions
epics-util: support for numeric primitive collections
epics-util: support for array backed primitive collections
epics-util: performance study and tests for array backed primitive collections
epics-util: support for numeric ranges
vtype: support for alarm/alarmSeverity/alarmStatus
vtype: support for time information
vtype: support for numeric display information
vtype: support for numeric scalars
vtype: support for scalar enumeration
vtype: support for string scalar
vtype: support for numeric arrays
vtype-json: support for JSON serialization of numeric scalars
vtype-json: support for JSON serialization of scalar enumeration
vtype-json: support for JSON serialization of string scalar
vtype-json: support for JSON serialization of numeric arrays

[shroffk]

@gcarcassi the travis failures have been fixed on the master.
can you do a rebase of your branch on the master? that should solve the travis build error

[ralphlange]

Are you sure this should go into the bundling project?
Until now, all code is in other repos, i.e. git submodules.

[gcarcassi]

Hi Ralph,

We have been discussing this with Kunal, and it may make sense to consolidate. Since we are going to redo the general purpose client and start adding the libraries in epicsCore, that would mean in the long run adding say another 10/15 maven projects, all with tight coupling, all that are going to be released on the same schedule. This would mean creating the same number of git repository, and then keep updating all the references... which also mean you can't simply do the maven release and so on. Already is a pain now: I have to update pvDataJava to get the extensions for generic arrays that are in epics-util. I do not have a way to do one pull request with both changes. It has to be broken into two pull requests which have to be synchronized. So, Kunal and I agreed to start putting the new projects there directly.

Note that this is exactly what happened with pvmanager/diirt. We started with separate repos and it quickly become not practical... But in the end, it's up to whoever to decide.

[ralphlange]

Been there, done that. I know these are valid arguments.

However, this PR introduces a change of concept. So: who is to decide?

[gcarcassi]

I have no idea. You have a nice spelled out process, right? :-)

My opinion is always: the person that manages the release. That's the one who has to handle the pain and should be the one to have ultimate control. Who is that for the Java stuff? You? Kunal? Whoever that is...

[ralphlange]

Could we at least mention it in the next Core Developers telecon?

[gcarcassi]

Totally. I think Kunal is not going to merge this before then, because he wants to discuss it there.

[shroffk]

Yes, I plan to bring this up at the next meeting and only after some deliberation accept this PR.