Contracts instrumentation: hide unhelpful "no body" warnings

[tautschnig]

Contracts instrumentation using inlining and has facilities to inspect warnings to ensure no unexpected warnings arise. The expected ones, however, should not be forwarded to the user as they cannot do anything about them.

Closes: #8639

• Each commit message has a non-empty body, explaining why the change was made.
• n/a Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• n/a 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).
• n/a My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.39%. Comparing base (4a1a325) to head (6356953).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #8697      +/-   ##
===========================================
- Coverage    80.40%   80.39%   -0.01%     
===========================================
  Files         1688     1688              
  Lines       207403   207404       +1     
  Branches        73       73              
===========================================
- Hits        166763   166750      -13     
- Misses       40640    40654      +14     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[kroening]

Didn't we make those hard errors?

[tautschnig]

Didn't we make those hard errors?

They are fatal assertions during property checking, yes. But goto-program inlining doesn't treat them as such (which is correct, because a later stage may still provide implementations).

[kroening]

They are fatal assertions during property checking, yes. But goto-program inlining doesn't treat them as such (which is correct, because a later stage may still provide implementations).

How does that work? We usually link first, and then inline?

[kroening]

This smells like the contracts instrumentation workflow needs to be cleaned up.

[remi-delmas-3000]

For some contract built ins
the bodies are generated during instrumentation by goto-instrument. They are still declared in cprover.h hence the warnings from goto-cc, goto—instrument