Add JavaScript extensions

[rderooij]

Integrated the Alfresco JavaScript Extensions (from alfresco-jscript-extensions by jgoldhammer) into OOTBee Support Tools. This PR adds several new root objects to the JavaScript API.

[AFaust]

@rderooij Sorry for not getting back to you earlier on this PR. First of all, thanks for the suggestion to integrate a fork of that extension into the OOTBee Support Tools. Since I personally have never used that addon (it adds functionality I found potentially problematic or going beyond what I thought "should" be made available), I am not that familiar with its current compability state.
What is your rationale for suggesting this integration? I see the original project is still available on GitHub, though it hasn't had a new commit in 4 years. It can be installed separately alongside the OOTBee Support Tools to add the script root objects, without necessarily having to integrate it into this project. Is there a compatibility issue with specific (newer) ACS versions that won't get fixed in the upstream project (anymore)? Do you foresee the space for other improvements that won't find a place in the original project, maybe because the maintainer is non-responsive/unavailable?
I am open to merging this integration if the original project is "dead" and this is the only means to keep the functionality available for the community. I may want to add configurable enablement flags for specific root objects in the future to control those I don't want to have (easily) available. There is certainly an argument to be made that even without these root objects, problematic API is available via reflection / Spring context access - my personal preference is just to not make certain dangerous features "too easy to use" that may lead up to some admin shooting themselves in the foot.

In case we go ahead (the original project is dead), could I ask you to apply the common code style used in this project to your contribution? Alternatively, if you were to allow reviewers to push changes to your PR branch, I could apply the code style and additional cleanup (removing commented code, logging and/or config improvements, ...) before doing the actual merge.

[rderooij]

I have updated the code based on the style guide.

The original project latest release was in 2017. There is a 1.8 release from 2021 in Maven, but it is no longer compatible with recent versions of ACS. The rationale in my view is that jconsole is part of OOTBee, so why not make jconsole more useful with some extra root objects.

I did not try to create a pull request to the original creator. I could try that first to validate whether the project is 'dead'.

[AFaust]

Since I have a long weekend with Monday off and you provided #272 last week, I managed to take some time to work with this PR locally. The following are the things I noticed:

• some classes / objects are not convenient for use / cannot be used as expected, i.e. globalProperties['db.pool.max'] should work and not necessitate a globalProperties.get('db.pool.max') - this is functionality as-is with the original extension and not something to be fixed for this PR, but a task should/will be created once merged to improve this in the future
• the ScriptDatabaseService uses javax.sql.DataSource, and ScriptTransaction uses javax.transaction.* as imports - this poses problems with ACS compatibility, does not work on newer releases (this is what made Handle NoClassDefFoundError when collecting Tern definitions #272 necessary), and must be addressed before merging
• a lot of code uses PreConditions.checkNotNull(T, Object) from a Google library instead of the Alfresco standard ParameterCheck.mandatory(String, Object) - this is functionality as-is with the original extension and not something to be fixed for this PR, but a task should/will be created once merged to improve this in the future
• some code uses commons-lang3 for its StringUtils and RandomStringUtils classes - this library is directly included in ACS from 7.0 onwards (indirectly/accidentally via transitive dependencies sometime before) and thus such code potentially breaks backwards compatibility of OOTBee Support Tools for ACS 5.x/6.x and should be replaced with version-agnostic code before merging (StringUtils.isNotBlank(String) and similar can always be easily replaced with standard Java String checks)
• some code has package-protected visibility with no apparent reason (ScriptRepository)
• some annotations supposed to document operations seem like copy&paste and do not always match the actual operation (i.e. in ScriptPolicies) - this is already the case in the original extension and should be addressed in the future since we do generate our API tern definitions from some of these details
• some LGPL copyrights included in the original source code have not been merged into the general file header - they should be part of the notice about forking from alfresco-jscript-extensions
• the job-related API (ScriptJobService and related) uses Quartz 2.x API which is binary incompatible with Quartz 1.x and thus breaks backwards compatibility of OOTBee Support Tools for ACS 5.x - due to the extension from Alfresco classes, it is not possible to avoid this without non-trivial refactoring
• some code uses Commons Logging instead of SLF4J - this is inherited from the original extension, and should in the future be standardised (eliminating those pesky isXXXEnabled() checks + if-blocks in most cases where they are unnecessary if placeholders are used in log messages)

Since the PR branch is not writeable to me, how'd you like to receive suggestions / changes from me on how to solve the library / API incompatibilities, which would be the primary blocker for merging for me at the moment?