Support Value Classes 2.0

There is a discussion in `Kotlin` about `value class` with multiple fields(`MFVC`).
https://github.com/Kotlin/KEEP/pull/339

This issue summarizes the `MFVC` support in `jackson-module-kotlin`.
Please note that `MFVC` has not yet been formalized and with the current update policy of `jackson-module-kotlin`, support may not be implemented for several more years.

The following `DTO` is used in the following description.

```kotlin
@JvmInline
value class MFVC(val v1: Int, val v2: String, val v3: String?)

data class Data(val v: MFVC)
```

## About serialize
As for serialization, it is likely to be supportable.

When serializing `MFVC`, we believe that it should be the same as a normal class.
In other words, the `Data` class above would be serialized as follows

```json
{
"v": {
"v1": 1,
"v2": "2",
"v3": "3"
}
}
```

To achieve this, we need to exclude unboxed getters generated for each `MFVC` property.
At the moment, the `Data` class above generates four getters: `getV`, `getV-v1`, `getV-v2`, and `getV-v3`, which means we have to exclude `getV-v1`, `v2`, and `v3`.

There are two possible ways to do this.

The first is to exclude all but `Kotlin Property` from the serialization result.
You can distinguish unboxed getters in that they are not `Kotlin Property`.
However, this would be a destructive change and would likely be implemented as an option.

The second is name-based exclusion.
The separator in the name of an unboxed getter could be changed to a more special name, such as `-$`.
https://github.com/Kotlin/KEEP/issues/340#issuecomment-1747297840
If this change were made, it would make it easier to exclude by name only.

Personally, I prefer the latter method.
The latter method is easier to implement, whereas the former is more complex to implement, and the `getter-like` function is no longer available.

## About deserialize
Supporting deserialization appears to be very difficult.

For the `Data` class, the constructor that `jackson` can call is probably of the form `Data(int,java.lang.String,java.lang.String)`.
This is the unboxed form of each property of `MFVC`.
This means that the number of arguments does not match the number of parameters in `Kotlin` (= number of properties in `JSON`).

I haven't done any deep research, but I can't think of any way to support this in `Jackson`.

If the `@JvmExpose` annotation is provided by `Kotlin`, there may be no other way to use it.
https://github.com/Kotlin/KEEP/pull/331