This limits the search for identifiers, statements, and source code
to the current container, by adding the following condition to the
corresponding sub-queries:

    origin_con_id = sys_context('USERENV', 'CON_ID')

This may make the query faster in multitenant environments, by querying
only the partitions for the current container, as opposed to all the
partitions when this condition is not used.

This fixes issue #34:

    ORA-01489: result of string concatenation is too long

by ensuring that the length of name_path remains <= 4000 bytes,
replacing as many levels as necessary by .../ starting from
level 4, so the first 3 levels are always kept, and the tailmost
levels should be preserved too.

These 2 additional columns might help in cases when it would
be useful to known on which line of code a given top-level
function/procedure ends.

plscope_identifiers: in the tree_plus subquery, ensure that
the is_new_proc column applies only to functions or procedures.

(This amends commit 5bf7d93.)

In 12.2, upon creating the dependent view plscope_tab_usage
the following exception would be raised:

  ORA-00600: internal error code, arguments: [17090], [], ...

Joining directly with dba_statements, and removing the stmt
materialized subquery as a result, fixes it.

Also coerced the procedure_scope and is_fixed_context_id columns
back into varchar2.

Reason: that column is cool and "nice-to-have", but...

1) It takes an additional outer join with the dba_statements view,
   which could be costly, and further that join cannot be eliminated
   even if that column is not used in the end: that join would always
   be there.

2) End-users may easily add that join if and when they need it.

To summarize, it's non-core functionality, and potentially costly,
so we'd better not have it in the core view.

(The same could be said of the "text" column BTW, which requires a
rather costly join with dba_source... But that column was there before,
so we'll keep it for now.)

Reason: required for pull-request.

I'd argue that EXECUTE is not the best choice of a pseudo-usage
name for SQL statements--we're not executing anything, this is
static code analysis, and all about usages of identifiers/SQL
statements... But it's been EXECUTE so far, and that change is
not ready to be merged yet.

This limits the length of the name_usage column to at most 250
characters, wrapping the value to the left if necessary. Without
this there remained a small possibility to hit the ORA-01489
"result of string concatenation is too long" exception when
computing that value, at least in principle.

plscope_identifiers: fix procedure_scope in case of forward decl. + other fixes/chg

…lumn aliases)

reason: In an multitenant environment the root container contains
some objects that are compiled with PL/Scope. These are the
PL/SQL packages STANDARD and DBMS_STANDARD and the
public synonym DBMS_STANDARD. This means beside the
sys_context('USERENV', 'CON_ID') the CON_ID 1 is also relevant.
Excluding the root would might lead to additional broken hierarchies
which are unnecessarily handled later on. In the end the result
might be incomplete, especially if one would like to analyze the
usage of objects in the root.