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 PhilippSalvisberg#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.