[lworld] RFR: [DRAFT] [lworld] Test scalarization and call conventions for different value class shapes

[Galder Zamarreño]

This is a **very early draft** for a template-based test (temporarily called `TestOne`) that addresses some of the requirements of JDK-8364421.

**NOTE**: the PR also includes the commits to add template-based testing framework since that's not yet in `lworld`, and also adds https://github.com/openjdk/valhalla/commit/68e4a60c1ff62f4d0b8b31cb0bd729f1d67748e2 so that Boolean types are supported in `checkEQ`.

This test has surfaced [JDK-8365590](https://bugs.openjdk.org/browse/JDK-8365590) bug, and as I focus on that bug, I thought it'd be a good moment to share what I've done so far with the test and get some feedback.

The test is very simple so far, creating value classes that contain a single field, testing for each of the primitive types. I also started testing having this field be a primitive array type and that's when I encountered [JDK-8365590](https://bugs.openjdk.org/browse/JDK-8365590).

I've tried to create value classes that had multiple fields, but I've hit some obstacles here so I've just added a very basic test:

First, I tried to use data names to create value classes that would have N fields, and have these fields initialized via a constructor, but I couldn't get it to work. So the example present in the test uses external data structures to keep track of these fields, their types, their initial values...etc. I have discussed these issues in more detail with @chhagedorn and bounced some ideas of how to improve data names, but these need to be discussed in more detail.

The second obstacle I found is related to nuances on when value classes with multiple fields will be scalarized, when these classes are part of another value classes. Depending on the combination of fields, they can be considered that they can be flattened or not, so handling this in a test like this would need to track the sizes of each fields, add them up, and decide whether the test should be positive on scalarization or negative. I traced this logic to `FieldLayoutBuilder::compute_inline_class_layout` and the way `_nullable_layout_size_in_bytes` is then used to decide whether to flatten or not. I've been using `PrintFieldLayout` option to see what nullable flat layout values each of these box instances would have.

So, given these complexities of multiple fields, I'm might keep `TestOne` (note: name is temporary) focused on value classes with a single field. And then have another test with multiple fields.

-------------

Commit messages:
 - Comment print inlining flag usage
 - Added ForceInline to make sure constructor gets inlined
 - Discovered bug in int[] box
 - Remove hardcoded MyTimeInstant references
 - Add a multi type that works just about
 - Merge branch 'valhalla.lworld' into topic.template-101
 - Comment failing IR test combination
 - Test value class within value class failing but reason unknown
 - Avoid using FieldConstant on uni field test
 - Basic test with multiple fields of boolean
 - ... and 11 more: https://git.openjdk.org/valhalla/compare/67e6bcc4...8adfff69

Changes: https://git.openjdk.org/valhalla/pull/1522/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1522&range=00
  Stats: 8478 lines in 38 files changed: 8374 ins; 2 del; 102 mod
  Patch: https://git.openjdk.org/valhalla/pull/1522.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1522/head:pull/1522

PR: https://git.openjdk.org/valhalla/pull/1522