Support jline.jansi alongside fusesource.jansi

[Oondanomala]

Jansi has been merged into JLine, which changes the package name (and the system property name).
This pr updates the code to use the updated package name.
Support for the old name is kept to avoid breaking changes. (though I can remove it if it's not wanted)

I chose to prefer the older one if both versions are available to avoid potential breakages, but I can change that if choosing a more up to date version is preferred.

Note: the out field is private in the new versions, so I switched to the method with the same name (which has always been there so there is no compatibility concern) so I switched to calling isInstalled instead (which should be more correct anyway). This means Jansi versions older than 2.1.0 will not work. Hopefully that's not a problem.
To support both old and new versions of Jansi, it will first try to call isInstalled (which should be more correct anyway) and only fall back to the previous method if isInstalled is not present.

Fixes #2437

[remkop]

Thank you!
Let me take a look later, hopefully this weekend.

[Oondanomala]

Turns out calling the out method initializes the output stream, so I've replaced it with a call to isInstalled, which should be more correct anyway.

isInstalled was "only" added in Jansi 2.1.0 (released 6 years ago), hopefully it's fine to drop support for anything older.

[garretwilson]

Good news; JLine has now been modularized, so any native allow overrides needed to be passed to the JVM can now be more granular. But it looks like one may not need the native portions of JLine even.

Please read this excellent summary covering how JLine can be used and whether native is even required (it probably isn't). @Oondanomala , you might want to check that summary to make sure the solution you're putting in is compatible with its recommendations.

[Oondanomala]

picocli only uses (reflectively, so there is no dependency) Jansi to check whether it has been installed so it can enable ansi on Windows, so it specifically "needs" (it will work fine without it, as it does not attempt to install it itself) the native module and only that one. It has its own code for making ansi codes.
So as far as I can tell that should not affect anything :D

And while modern Windows terminals support ansi without needing to install Jansi, considering picocli still supports Java 5 I would say it's best to keep supporting old terminals :)
There should probably be a check to enable ansi codes on modern Windows terminals that support ansi without needing Jansi, but that is for another PR.

That said, I noticed the test suite actually depends on an even older version of Jansi before 2.1.0 for Java 5 compatibility,
so I added back support for reading the out field directly if isInstalled isn't available.
This means the PR now does not drop support for any Jansi version!