[foreign-jextract] RFR: 8262198: Overhaul bitfield parsing logic

[Maurizio Cimadamore]

This parsing stratgey cannot (by definition) fail - so, moving forward there will be no more exceptions coming from this side of the code. Of course, since we no longer have container classification, when bitfield support is added to the backend, things might be a bit tricker; however I realized that, since the layout is well-formed, the backend can always use the layout API to query the offset and size of a given bitfield, and decide on the best strategy to get there (e.g. get the closed 8/16/32/64-bit word and apply some bitmasking). So, perhaps things don't change much in terms of code generation support.

This patch fixes a small bug in Parser, where we where creating the same tree twice (!!). There are some small tweaks to TreeMaker, to work with the new bitfield info coming out from RecordLayoutComputer, but overall nothing too difficult here.

Note that the `BadBitfieldTest`, which was previously asserting a jextract crash, has now turned into a positive test (and I've dropped the exclusion on Windows, since the test should now pass on all platforms).

[1] - https://github.com/rust-lang/rust-bindgen/issues/743

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

Commit messages:
 - Consolidate code for bitfield testing
 - Re-enable BadBitfieldTest for Windows
 - Rewrite bitfield support

Changes: https://git.openjdk.java.net/panama-foreign/pull/459/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=459&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262198
  Stats: 154 lines in 10 files changed: 34 ins; 102 del; 18 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/459.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/459/head:pull/459

PR: https://git.openjdk.java.net/panama-foreign/pull/459