Enable flagging all queries for an app as secure before configuration of protector queries

[varontron]

This will eliminate an attack vector caused by latency

[varontron]

This along with #37, #35, #34, and part of #33 will require some additional attributes. This came to light during work on #33 when coding up the method to populate the security panel with existing plugin configuration data. It turns out the following scenario is ambiguous:

YADA_PARAMS table:

TARGET	NAME	VALUE	RULE
APP qname	pl	Gatekeeper	1

• Is the plugin security related?
• If it's a TokenValidator implementation, there's no argument required.
• How do we tell the difference between this and any old plugin? We can't.

To clarify, any other security setting, e.g., execution policy, content policy, url pattern, can be distinguished by the presence of an arg string

TARGET	NAME	VALUE	RULE
APP qname	pl	Gatekeeper	1
APP qname	pr	execution.policy.columns=...	1

But even in this case, what if the user has created the query, but not actually locked it down (this very issue #39).

There is also a confounding condition, namely multiple plugins. While multiple plugins might not be supported currently (untested) they certainly should be. The arg strings will merge. How to tell which plugin class is sec-relelated?

Enter YADA_PROP (YADA properties table):

CREATE TABLE IF NOT EXISTS YADA.YADA_PROP
( 
  TARGET VARCHAR2(500), 
  NAME VARCHAR(500),
  VALUE VARCHAR(4000)
);

The TARGET can be a YADA qname, app, system, some id string, etc.
NAME and VALUE are strings.

I believe it will also be necessary to include an ID column in the YADA_PARAM table to attach properties to each row. The YADA_QUERY_CONF and YADA_QUERY_TABLE have defacto PKs already. ID will act like a PK but constraints will be implementation specific, not required.

For now, these will load into the admin tool for marking and distinction purposes, specifically around security. In the future, these could be used to short circuit plugin activation in the Service layer, hold system-wide configs (like JAVA_OPTS), ui prefs, etc.