Factor out solver resource limits capability

[peterschrammel]

That need not be a part of prop_convt.

• Each commit message has a non-empty body, explaining why the change was made.
• Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
• Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
• My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[martin-cs]

I believe that this works as described. However, while we are on the subject, please can we add a reproducible resource limit? We should only be using time limits as an absolute last resort option, to the point I am almost tempted to say this interface should be deprecated! (For people who haven't come across this problem before -- it is really important that CPROVER is deterministic, a whole bunch of things become really nasty if it is not.) The SMT-LIB standard has had reproducible resource limits for many years and it would not be hard to implement in our back-end. While we are working on this bit of code, please can we do something about this?

[peterschrammel]

@martin-cs, happy to discuss this separately from this PR. I'll ping you.

[allredj]

⚠️
This PR failed Diffblue compatibility checks (cbmc commit: 4896d61).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/106156861
Status will be re-evaluated on next push.
Common spurious failures include: the cbmc commit has disappeared in the mean time (e.g. in a force-push); the author is not in the list of contributors (e.g. first-time contributors); compatibility was already broken by an earlier merge.