Support for custom CDN version

Hello @dcam,

The PR has been merged: github.com/NUKnightLab/TimelineJS3/pull/894

I figured it would be best to allow for:
- Leaving the recommended version (3.8.18)
- Allowing for a custom version from CDN (using web/library in our project is quite complicated as it's not a simple drupal setup)
- Keeping all else the same, and seeing default to recommended.

I have tested this locally and works well, can confirm setting different version in settings works and entered version are the ones loaded.

To be honest, from my perspective if people want to serve a different, specific version then they should host it locally. Or the library definition can be overridden in a custom theme. In other words, my initial inclination is to put the burden for customization on the person who wants to do the customizing. But I'll give it some thought.

I would like to kindly provide some important points for consideration:

* Using a CDN has it's benefits, no need to argue such point as the module currently provides a settings form for using CDN (latest version and hard-coded 'recommended' version)

* The original issue reported in ticket 3524525 was due to the module recommending and providing a specific version to a very old release (11 versions behind, and 4 years old)

* As you stated in the ticket using 'latest' could break on major releases, and locking it down is preferable. I would perhaps question this option before having a users lock a specific version.

The solution for ticket 3524525 was to hard-code "3.9.7" and make it available as a new option. How different is this from a user choosing custom and typing in 3.9.7... or 3.9.8 for that matter? This new setting ensures ticket 3524525 is never an issue again -- allows both selection and locking the version.

Selecting a version of the TimelineJS3 library, and keeping that library up-to-date, is not a customization. Now, perhaps patching the library and working with a forked version -- definitely. In this case, yes... I understand your point.

I do not see why add this burden to a person simply because they want to use a specific, already hosted, version of the library. Although it sounds simple enough, on complex systems (that contain a large amount of modules/profiles/libraries/patches/configuration which change according to sub-projects) this increases complexity and may create confusion as to the source of the library.

Also having to add a library via a theme or module on a system where different themes/modules may be selected is less than ideal. Yes, I know it's possible but as you say... a bit of a burden when simply using the module settings is rather straightforward, easy to follow, and wonderfully convenient for official releases of the library.