Refactor string_constantt::get_value and string_constantt::set_value call sites.

[NlightNFotis]

Refactor string_constantt::get_value and string_constantt::set_value call sites.

The functions were marked DEPRECATED over the value() calls (they were already working by dispatching to value(), so they were kind of a useless indirection/duplication).

[codecov]

Codecov Report

Attention: 8 lines in your changes are missing coverage. Please review.

Comparison is base (b836b4f) 77.98% compared to head (db61a6a) 77.86%.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #7999      +/-   ##
===========================================
- Coverage    77.98%   77.86%   -0.12%     
===========================================
  Files         1701     1701              
  Lines       196502   196496       -6     
===========================================
- Hits        153245   153010     -235     
- Misses       43257    43486     +229     

Files	Coverage Δ
src/analyses/custom_bitvector_analysis.cpp	55.96% <100.00%> (ø)
src/ansi-c/ansi_c_convert_type.cpp	79.95% <100.00%> (ø)
src/ansi-c/c_storage_spec.cpp	97.56% <100.00%> (-0.12%)	⬇️
src/ansi-c/c_typecheck_code.cpp	80.41% <100.00%> (ø)
src/ansi-c/expr2c.cpp	67.83% <100.00%> (-0.02%)	⬇️
src/assembler/remove_asm.cpp	77.91% <100.00%> (ø)
src/cprover/axioms.cpp	92.11% <100.00%> (ø)
src/goto-programs/string_abstraction.cpp	90.93% <100.00%> (ø)
src/goto-symex/shadow_memory.cpp	93.03% <100.00%> (ø)
src/statement-list/statement_list_parser.cpp	95.86% <100.00%> (ø)
... and 9 more

... and 88 files with indirect coverage changes

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

[thomasspriggs]

This should probably be 2 commits. A first commit removing the usage and a second commit removing the functions. That way if any downstream users temporarily want the functions back, then it is easier for them to revert the second commit without reverting the first (in their fork / subtree).

[NlightNFotis]

I thought there was a rule for commits to be atomic and buildable for each one of them, in case there needs to be a bisection or something else happens that lands a developer on the commit and needs to build it.

In that case, if I split this into two commits, the first one is not going to be buildable.

EDIT: We discussed it further offline, and it seems that there's a way forward with this that doesn't result in the first commit being broken.

I will be working on this and update the PR correspondingly.

[tautschnig]

Quoting our coding guidelines:
"Any deprecated functionality should remain in place for at least six months from the date of deprecation. Before deprecating code, all in-tree uses should be replaced or marked as deprecated."

So let's please have the first commit, and put the second commit in a PR of its own that should remain in Draft state for the next 6 months.

[NlightNFotis]

@tautschnig Done (cleaned up this PR). Will raise the other PR as draft now.

[NlightNFotis]

Okay raised draft PR for the second part at #8003