Define isKnownNonZeroLength for delimiters

[aaronmbauman]

What

ModelGroup.hasFraming answers whether a delimiter is written in the schema,
not whether it occupies bits in the data stream. A %ES; or %WSP*; delimiter
matches zero-length data, so per DFDL spec section 9.2 it is not framing.

Because hasFraming short-circuits hasKnownRequiredSyntax, a group framed only
by such a delimiter counts as definitely non-zero-length and is denied separator
suppression: parsing raises a spurious Failed to find infix separator, and
unparsing writes a trailing separator that does not belong.

The zero-length test now runs per literal in the delimiter list, and splits in two:
isKnownCanMatchEmptyString for the framing analysis, and hasZeroLengthEntityAlone
for the narrower restriction section 12.2 actually states.

Evidence

The same TDML suite run against main and this branch (TestSequenceGroupZLFraming):

	main	this branch
parse: esInit_absent, esTerm_absent, wspInit_absent, esChoice_absent, esInitList, wspWspInit, esTermList, exprTermReal	8 fail, Failed to find infix separator	pass
unparse: esInit_absent_unparse, wspWspInit_unparse	output data length 2 for 'X,'	writes X
controls: ctl_*, esInit_present, constTermReal, ...	pass	pass

Every case has a control that differs only in the delimiter on the inner model
group, so a control failure means the harness is broken rather than Daffodil.

Full daffodil-test against this commit: 4725 tests, 0 failures (4724 passed,
1 skipped, 115 ignored), on Ubuntu 22.04 / JDK 17 / Scala 3.3.7.

Notable for reviewers

• checkModelGroupZL: it asserts that a model group which parsed zero length
  was analyzed as possibly zero length. That could not hold while a %ES;
  delimiter counted as framing, so the assert was commented out in 53d6b4f
  (2018). It is enabled again.
• dfdl:initiatedContent='yes': an initiator list such as "P %ES;" is now a
  Schema Definition Error, as section 12.2 requires. Such schemas used to compile
  and parse, so the commit message carries a Deprecation/Compatibility note with
  a migration path, covered by emptyInitiator8 and emptyInitiator9.
• Deliberately permissive: for an expression-valued delimiter we answer "not
  known to occupy bits", which accepts input previously rejected. That is what
  mil-std-2045 needs. It cannot be narrowed statically, since an expression
  returning %ES; and one returning a real delimiter are indistinguishable at
  compile time.
• Alignment untouched: AlignedMixin keeps using hasSeparator. A delimiter
  that can match zero length can also match non-zero length, so asserting zero
  length there would risk silent misalignment.

On separators

The issue's requirement is to define isKnownNonZeroLength for delimiters so the
term-level calculations are correct, which this PR does for initiators and
terminators. It also notes the predicate can be false for separators where
lengthKind is not 'delimited'. I tried that: SeparatorCooker is
DelimiterCookerNoES, so a constant %ES;/%WSP*; separator is already an SDE and
never reaches the framing analysis, and wiring the same predicate into the separator
paths changed no observable behavior across four schema shapes, so I backed it out
rather than ship an untestable change.

Also found while testing, unrelated: dfdl:separator="%WSP*;%WSP*;" passes the
cooker and then aborts in the delimiter DFA (Assert.impossibleCase,
dfa/Rules.scala:117) on main too. I can file that if you want it tracked.