[FIRRTL][OM] Add property asserts

[seldridge]

Add support for a FIRRTL property assert and an OM property assert. This
is intended to allow for front-end language users to define metadata
constraints. These constraints are either compile-time known to be
true/false or they are evaluated at metadata evaluation time.

This is part of building towards adding FIRRTL domain constraints. At
present, FIRRTL only has maximally unsafe firrtl.unsafe_domain_cast
operations. We'd like to have the ability to do this unsafe cast, but
apply additional constraints. E.g., for a synchronous clock domain
crossing, we'd like to be able to say that the crossing must be between
two domains which are synchronous to each other. However, at present we
cannot do this and a synchronous crossing looks the same as an
asynchronous crossing. This is infrastructure to enable this kind of
check.

Commits are logical and should be reviewed independently.

AI-assisted-by: Claude Code (Claude Sonnet 4.6, Claude Haiku 4.5)

[fabianschuiki]

Results of circt-tests run for 7eb04bf compared to results for 5dc62fe: no change to test results.

[mikeurbach]

The general boilerplate and plumbing of new ops through the pipeline looks good to me, as do the actual op definitions.

Just a couple comments on the evaluator and some edge cases that I don't think this handles.

[mikeurbach]

besides constant attributes, this could also be a field of an object. we have to handle something like that in the arithmetic ops for example:

circt/lib/Dialect/OM/Evaluator/Evaluator.cpp

Lines 461 to 473 in 0fde1fe

	// Extract the integer attributes.
	auto extractAttr = [](evaluator::EvaluatorValue *value) {
	return std::move(
	llvm::TypeSwitch<evaluator::EvaluatorValue *, om::IntegerAttr>(value)
	.Case([](evaluator::AttributeValue *val) {
	return val->getAs<om::IntegerAttr>();
	})
	.Case([](evaluator::ReferenceValue *val) {
	return cast<evaluator::AttributeValue>(
	val->getStrippedValue()->get())
	->getAs<om::IntegerAttr>();
	}));
	};

i would add some evaluator unit tests for this change in general. a couple edge cases we test for the arithmetic operations is a) the evaluator value is from object fields, and b) the evaluator value is from object fields, and there are cycles such that the value isn't ready right away.

specifically for that latter b) case, we have this isFullyEvaluated handling, which I don't see here yet:

circt/lib/Dialect/OM/Evaluator/Evaluator.cpp

Lines 441 to 453 in e712f4d

	// Evaluate operands if necessary, and return the partially evaluated value if
	// they aren't ready.
	auto lhsResult = evaluateValue(op.getLhs(), actualParams, loc);
	if (failed(lhsResult))
	return lhsResult;
	if (!lhsResult.value()->isFullyEvaluated())
	return handle;
	auto rhsResult = evaluateValue(op.getRhs(), actualParams, loc);
	if (failed(rhsResult))
	return rhsResult;
	if (!rhsResult.value()->isFullyEvaluated())
	return handle;

[uenoku]

Is a label needed even wen OM assert doesn't have one?

[seldridge]

It's questionable. Probably not. This is now used in the lowering to the OM asserts, however, it's just used as a prefix if it exists.