A bit of refactoring in the data engine, to improve type safety

[hvbtup]

There are no functional changes.
Added types to many collections.
Removed unnecessary casts.
Removed unnecessary SuppressWarnings tags.
Removed the class PropertySecurity, because it just routed to System.getProperty.
Simplified some if-else constructs as suggested from the IDE.

All of this in an attempt to make the code at least a little bit more comprehensible.

[hvbtup]

I see that the commit message is wrong. In fact I started with the intention to fix endless JDBC ParameterMetaData log messages, but then I saw that the code used untyped collections everywhere. So I began to add types to the collections. I commited, and later continued with the typing work.
Finally I came to the conclusion that a PR should not deal with more than one topic, so I removed the changes regarding JDBC ParameterMetaData log messages again.

[speckyspooky]

I have checked the replaces and the changes to the typed collections looks good.

[hvbtup]

@wimjongman Can you take a look at the code?
I have to say that I'm not an expert on typed collections in Java.
Is there any risk that code outside of the BIRT project (eg custom plugins) will break after this change, would such custom code need a recompilation, would this recompilation result in errors?
Probably nobody cares about a few warnings more or less, but if this would be a breaking change for plugin developers we should know it.
Do you know anybody who actually uses or develops custom plugins (for extend items)? Because I guess that would be the only place where this PR could possibly have a negative effect, so these people should test.

[wimjongman]

Sorry, I have no time to take a proper look at this.

[merks]

@hvbtup I think this generally looks fine. Downstream clients would be using mostly raw types at this point so mostly such changes would have no impact because the erasures stay the same...

[wimjongman]

Thanks, Ed!