Use null-check for allocators instead of try/catch

[osialr]

I wanted to compile the library with -fno-exceptions so this makes use of new (std::nothrow) in the allocators and marks the generated allocators as @NoException.

Also, it prevents JavaCPP_exception from being emitted when no exceptions are used in the code

[saudet]

C++ constructors are allowed to throw exceptions, so as per #84, could you make it so that only allocators for structs defined in a C header files and included via cinclude are annotated with @NoException?

Also, there are cases when handleExceptions doesn't get flagged, but where JavaCPP_exception gets used... I'll have to check that.

[osialr]

Oh right, allocate could call C++ ctors which could throw. The Parser would need to compare against cinclude

I'll close this one out and combine something with a variant of #86

[saudet]

BUT it's really not a good idea to have C++ destructors throw exceptions, so it's not something that we're likely to see... So I don't know, should we really remove throws Exception from Pointer.close() altogether? Maybe it makes sense in the sense that even if something were to get thrown from it, C++ doesn't have checked exceptions, so removing it from close() would look OK from the C++ side of things. What do you think?

[osialr]

It's true that C++ destructors shouldn't throw and the program may call std::terminate if it throws.

To play devil's advocate, removing throws Exception would cause a compile error for end-users that created a subclass with close() throws Exception. In the interest of backwards compatibility, it makes sense to leave it as-is until a 2.0.

[saudet]

I don't think any users created such subclasses. It's too new of a feature. ;) IMO, it wouldn't be a large API change, so for a 1.1->1.2 jump, I wouldn't have any issues with that. I just want to make sure that not having a checked exception is the best thing to do, regardless of versioning...