The fdt set command was treating properties specified as <00> and <0011>
as byte streams, rather than as an array of cells.  As we already have
syntax for expressing the desire for a stream of bytes ([ xx xx ...]),
we should use the <> syntax to describe arrays of cells, which are always
32-bits per element.  If we imagine this likely (IMHO) scenario:

> fdt set /ethernet-phy@1 reg <1>

With the old code, this would create a bad fdt, since the reg cell would be
made to be one byte in length.  But the cell must be 4 bytes, so this would
break mysteriously.

Also, the dts spec calls for constants inside the angle brackets (<>)
to conform to C constant standards as they pertain to base.
Take this scenario:

> fdt set /ethernet@f00 reg <0xe250000\ 0x1000>

The old fdt command would complain that it couldn't parse that.  Or, if you
wanted to specify that a certain clock ran at 33 MHz, you'd be required to
do this:

> fdt set /mydev clock <1f78a40>

Whereas the new code will accept decimal numbers.

While I was in there, I extended the fdt command parser to handle property
strings which are split across multiple arguments:

> fdt set /ethernet@f00 interrupts < 33 2 34 2 36 2 >
> fdt p /ethernet@f00
ethernet@f00 {
	interrupts = <0x21 0x2 0x22 0x2 0x24 0x2>;
};

Lastly, the fdt print code was rearranged slightly to print arrays of cells
if the length of the property is a multiple of 4 bytes, and to not print
leading zeros.

Signed-off-by: Andy Fleming <afleming@freescale.com>