AvetanaBluetooth JSR-82 implementation

A few people in the forums have had problems with the fact that
Bluez.createService() returns a C pointer, converted into a Java integer,
as a handle to the service it has created. There are two problems with
this:

1. On 64-bit systems, the pointer cannot be meaningfully converted since it
is 64 bits long and a Java int is just 32 bits. This breaks compilation on
64-bit systems.

2. Java ints are *signed* which means createService() often returns a
negative value. The trouble is that, according to the method's Javadoc, a
negative value means failure. Methods in Avetana that call createService()
stick to that interpretation and, as a result, they exhibit mysterious
"failures" depending on how malloc() feels at the moment :-)

I have created a patch which hopefully solves point No. 2. I have changed
the Javadoc so that only -1 indicates failure. I have also adjusted the
calling methods to this interpretation. Of course, when malloc() returns
0xffffffff then createService() will still indicate failure when it
shouldn't. I have no idea whether that's actually possible but at least it
should be very, very rare.

As for point No. 1, it should be solvable by changing the method's
declaration to return long rather than int. I'll leave that to someone with
a 64-bit system who can properly test it. It should be noted, however, that
it will only work until someone tries to compile Avetana on a 128-bit
system :-)

The patch was created using "diff -u" against avetanabt-20070719.tgz.