-lang qb/fblite: Don't unscope temp vars that should live in specific scope

The main problem was that SELECT CASE used symbAddTempVar() which will
unscope the temp var via FB_SYMBOPT_UNSCOPE under -lang qb/fblite, which
caused the temp var to be destroyed at scope breaks above the SELECT CASE,
since SELECT CASE also used symbUnsetIsTemp(), and that was bad because
the initialization code was still at the SELECT CASE, not at the top of
the procedure, thus these scope breaks above the SELECT CASE could try to
destroy an uninitialized variable.

In practive this only matters for SELECT CASE on dynamic strings, i.e.
fb_StrDelete() calls. SELECT CASE doesn't allow UDTs, and other types don't
have destructors at all anyways.

- SELECT CASE must use some kind of temp var, to store the expression
  result value, for comparison at each CASE
- the temp var can be a dynamic [w]string, which must be destroyed at the
  END SELECT, and also at every scope break out of the SELECT (such as
  EXIT SUB/FUNCTION)
- SELECT CASE uses an implicit scope to "capture" the temp var, so the
  normal scope breaking + dtor calling mechanism handles it
- for this however, the var must not have the FB_SYMBATTRIB_TEMP bit,
  because "TEMP" vars aren't considered for dtor calling at scope breaks.
  (instead, they're handled by the AST's dtor list and astAdd())
- hence symbUnsetIsTemp() was used
- The only problem was the unscoping done by symbAddTempVar() under -lang
  qb/fblite, which breaks the main assumption: That the temp var exists
  only within the SELECT CASE scope

This patch adds a symbAddImplicitVar() function, which is a short-hand
for symbAddVar() -- essentially the same properties, only the identifier
is auto-generated and it only allows passing the dtype/subtype, but no
array dimensions etc., for simplicitly. (If the compiler needs to create
a more complex implicit variable, we can just use symbAddVar() directly)

Like symbAddVar() (and unlike symbAddTempVar()), symbAddImplicitVar()
won't do -lang specific unscoping, thus making it the safer choice for
implicit variables in SELECT CASE or WITH.
symbAddImplicitVar = symbAddTempVar + symbUnsetIsTemp - unscoping

Assuming that a SELECT CASE will never be "unscoped" (moved to the top
of the procedure), it makes sense to prevent unscoping for its implicit
variable.

Otherwise, the only solution for the original problem of fb_StrDelete()
calls on uninitialized string vars is to "unscope" their initialization
code too. However, then the SELECT CASE code would already have to check
fbLangOptIsSet( FB_LANG_OPT_SCOPE ), in order to decide whether to use
astAdd() or astAddAfter() for the implicit var's DECL node, just as done
by parser-decl-var. At the moment this seems unnecessary to me though.