					General design.

There are four big parts of the code:
 1. Translation
 2. Authorization/Authentication
 3. Output handler
 4. Logging handler
Translation handler finds match for the request URL, if found, sets
output handler to plsql, otherwise simply returns DECLINED.
Initially I wanted to open database connetion right here, but something
stopped me from doing it. Since I don't remember what was it, I'll
probably go back to this in next release.

Authentication handler calls authorize function, and sets an entry in 
r->notes with key plsql-auth-success and value true or false. It is needed
for authorization handler, which should simply return same thing as
authentication: OWA doesn't have a concept of authorization, and I'm not
sure wheter I want to let other modules to step in here. I'm still in
doubt though.

Output handler parses input data into linked list of name-valueS
structures (plsqlProcParam), sorted by name. If there are many parameters
with same name, they get into same structure. Then it finds a name of
procedure, forms anonymous PL/SQL blok, and calls it.

Logging handler simply iterates through requests, retrieving information from
oci_www.www_errors and writing it to corresponding log file. It also puts
oci_www.sys_errors into error_log using ap_lor_rerror.


			Few notes on connections to database.

First and most importand: unlike in owa, database connections are CACHED.
It means that you do not have state of your packages reinitialized with
every request. Commit still happens after each request, though.
The way connection caching works is very simple:
whenever module needs to do something with database, it calls "connect_cache".
This function 
	1. looks at URI of current request, and finds corresponding database
	   connection config file (db.conf)
	2. then tries to find an open connection, that corresponds to this
	   config file in expanded_did_dbs -- table of open database connections
	   keyd by config file path. It is allocated in per-child pool.
	3. If found, it checks for two things. First, if it was already called
	   during this request processing.
	4. If yes, then simply prepare db connection for use with this request,
	   and return it.
	5. Otherwise, it also checks if config file wasn't modified since
	   connection was open.
	6. If it was, closes connection.
	7. If it gets to this point, then connection needs to be open,
	   which it does.
	8. Then connection is set in expanded_dir_dbs, and returned to caller.

Problems, that I see with this:
	1. Memory leakage: all data for connection caching is allocated in
	   per-child pool, which means that all unsuccessfull connection
	   attempts will leave its memory hanging arround unused untill
	   child dies. Which is a problem if MaxRequests is set to infinity.
	   Not a big problem, since connection failures shouldn't happen
	   that often on properly configured servers.
	   It could be fixed by opening connection using data allocated on
	   stack, and then only allocating memory from pool only in case
	   of success, but I don't want to bother now.

