Adds preference "java.codeGeneration.generateCommentsInMarkdown" to
generate javadoc in markdown style

Server side changes :
eclipse-jdtls/eclipse.jdt.ls#3837

* Update ESLint to v10 (redhat-developer#4469)

* Address review comments

---------

Co-authored-by: MEHER SRUJANA MATCHA <mehersrujana.matcha@ibm.com>

Bumps  and [brace-expansion](https://github.com/juliangruber/brace-expansion). These dependencies needed to be updated together.

Updates `brace-expansion` from 5.0.7 to 5.0.9
- [Release notes](https://github.com/juliangruber/brace-expansion/releases)
- [Commits](juliangruber/brace-expansion@v5.0.7...v5.0.9)

Updates `brace-expansion` from 2.0.3 to 2.1.4
- [Release notes](https://github.com/juliangruber/brace-expansion/releases)
- [Commits](juliangruber/brace-expansion@v5.0.7...v5.0.9)

---
updated-dependencies:
- dependency-name: brace-expansion
  dependency-version: 5.0.9
  dependency-type: indirect
- dependency-name: brace-expansion
  dependency-version: 2.1.4
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>

…edhat-developer#4473)

The JVM derives sun.jnu.encoding - the charset it uses to decode and encode file
names on POSIX systems - from the process locale at startup, and silently
ignores -Dsun.jnu.encoding, so neither java.jdt.ls.vmargs nor -Dfile.encoding
can influence it.

Containers routinely start with an unset or C/POSIX locale, which makes the JVM
fall back to ASCII. Any workspace file whose name contains non-ASCII characters
is then decoded into U+FFFD and can no longer be turned into a
java.nio.file.Path, so importing the workspace fails with
"InvalidPathException: Malformed input or input contains unmappable characters"
and every project after the failing one is missing from the Java Projects view.
This is why the reported project only reproduces inside a container and works
fine locally and over SSH remote.

Correct the locale of the JDT LS process when, and only when, the inherited one
cannot represent non-ASCII file names. A deliberately configured non-UTF-8
locale such as zh_CN.GBK is left untouched, and only the LC_CTYPE category is
set unless LC_ALL is the variable selecting ASCII, so message, number and time
formatting keep following the environment.

Fixes microsoft/vscode-java-dependency#1041

See eclipse-jdtls/eclipse.jdt.ls#3850,
this is the client side changes needed to adopt that PR.

Signed-off-by: David Thompson <davthomp@redhat.com>

…dhat-developer#4484)

…before applying edits (redhat-developer#4482)

* implement confirmation for move instance method errors before applying edits

Signed-off-by: Morgan Chang <shin19991207@gmail.com>

* advertise support for move refactoring confirmation

Signed-off-by: Morgan Chang <shin19991207@gmail.com>

---------

Signed-off-by: Morgan Chang <shin19991207@gmail.com>