stray 'cflock' variable created when <cflock> or script equivalent is used

Use of <cflock> or the script equivalent ('lock') creates a variable 'cflock'
1) This is inconsistent with ACF (minor complaint - the fields in this struct could be very useful)
2) This variable is created in 'variables' scope, so it's a potential concurrency problem in CFCs

To avoid concurrency risk, it appears that we need to update all CFC methods which use <CFLock> or 'lock' to add a 'var' declaration for 'cflock' - In our codebase, this is a significant project and this won't completely resolve the conflicts, since locks can be nested

Suggested fixes:
1) remove the variable to restore ACF compatibility
2) add an optional attribute to <CFLock> so the results variable can be named (and don't create/update it unless this attribute is provided)

Exposure appears to be minimal, since we were able to use StructClear(cflock) within the lock block... which seems to indicate that this struct does not contain anything critical to the functioning of the lock.. however, concurrent updates to Map objects can be problematic, so there's a non-zero chance of mayhem, especially if someone writes code which uses the values (or, worse, tries to iterate over the members)

The following code demonstrates the stray variable creation - when run on ACF, the 'IsDefined' result is NO/false - on Lucee, it's YES/true:

<cfscript>
lock type="exclusive" timeout="10" name="kilroy"
{
WriteOutput("got the lock<br />");
}

WriteOutput(IsDefined("cflock"));
</cfscript>