Make componentt::{base,pretty}_name comments

[tautschnig]

The only semantically relevant name information is the ID_name entry.
Two components should not be considered different when they only differ
in their base_name or pretty_name. Thus, use ID_C_base_name and
ID_C_pretty_name, respectively, to store these.

The goto binary version is incremented as goto binaries compiled before
this patch are incompatible with the changes introduced here.

• 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

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

Comparison is base (74075ec) 79.09% compared to head (8e4f8e3) 79.09%.

Files	Patch %	Lines
src/ansi-c/expr2c.cpp	42.85%	4 Missing ⚠️
src/cpp/expr2cpp.cpp	0.00%	3 Missing ⚠️
src/goto-instrument/alignment_checks.cpp	0.00%	2 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #5815      +/-   ##
===========================================
- Coverage    79.09%   79.09%   -0.01%     
===========================================
  Files         1699     1699              
  Lines       196512   196516       +4     
===========================================
  Hits        155428   155428              
- Misses       41084    41088       +4     

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

[martin-cs]

Changes are fine but a change to the format number feels like it is worth a major or minor version number change.

[martin-cs]

Does this need a major or minor version number bump?

[tautschnig]

I don't know how many customers have use cases where they build goto binaries, store them, and (re-)analyse them at a later point in time. I know that's something I occasionally see, but I have no idea how common this is. So I'm with you that a version number change is desirable, but I'd lean towards minor-version-bump-is-sufficient. If others agree with this, then we could contemplate merging this PR just before one of the next regular version bumps (e.g., next Thursday).

[hannes-steffenhagen-diffblue]

I concur with @martin-cs, changing the goto binary format should be a major version bump as it's a pretty clear example of a breaking change.

While hopefully this would not impact too many people, this gives us an opportunity to tell people "Here, this breaks this particular use case, watch out for that, if you're not doing that you should be fine".

Of course in principle any change is potentially a breaking change for someone, but my view has been that if we know something is a breaking change it should result in a major version bump.

[tautschnig]

As side effect, this PR also sorts out the goto binary version bump that we will want anyhow with version 6 (and the breaking changes that we intend to merge as part of this).

[kroening]

As side effect, this PR also sorts out the goto binary version bump that we will want anyhow with version 6 (and the breaking changes that we intend to merge as part of this).

I haven't seen yet a convincing reason to do this -- I'd be convinced by the changes to the array type, but that needs more work.