Fix EF value-rep assertion crash (issue #366)

[disteph]

Fix EF representative-selection assertions and add regression tests (fixes #366)

Description
This PR fixes crash-on-valid-input behavior in ef_get_value_rep and adds regression coverage for issue #366.

What was wrong
Two assertion failures were reachable on issue #366 repro inputs in src/exists_forall/ef_values.c:

An unconditional assert(0) immediately after selecting/storing a representative (old line ~730).
A second assert(0) on cycle detection during recursive representative rewriting (old line ~759), reached after removing the first assert.
Fix
Remove the unconditional assert after store_rep(...) so representative selection can proceed normally.
Replace cycle-path abort with conservative fallback:
if a cycle is detected for argument f, keep f unchanged (frep = f) instead of asserting.
this avoids recursion blowups and preserves valid term construction.
Tests
Added regressions for both issue repros:

tests/regress/iss366a.smt2
tests/regress/iss366b.smt2
with .options using --timeout=1
with .gold expecting interrupted
These tests ensure the solver no longer aborts/asserts on the reported inputs.

Notes
This change is intentionally minimal: it removes debug-abort behavior and keeps cyclic subterms stable rather than failing hard.

[coveralls]

coverage: 67.277% (+0.02%) from 67.254% — bugfix/issue-366 into master

[disteph]

@BrunoDutertre : Not sure about this "fix". The first assert(0) looked strange. The second one about the circularity looked more like a situation where we want to give up, though assert(0) doesn't feel like the proper way to give up. Both asserts were hit by the use case from #366. Anyway, with the proposed fix the use case times out, so it's not clear it's better. If you have a better solution to handle the use case, it's welcome!