Rename RadicalGroup to SolvableRadical (the old name is still supported as an obsolete synonym)

[ThomasBreuer]

and added the treatment of RadicalGroup as an obsolescent variable

Note that there is the notion of radical (p-)subgroups of a group,
which means something completely different,
and that solvable radical seems to be the term used in the litarature.

(I guess that the name RadicalGroup had been chosen --a long time ago--
because Radical was too unspecific, and thus adding the suffix Group
provided at least some context.)

Please provide a short summary of this PR and its purpose here. E.g., does it add a new feature, and which? Does it fix a bug, and which? If there is an associated issue, please list it here.

Text for release notes

We track noteworthy changes as entries in the CHANGES.md file in the root directory of this repository. To help us decide whether and how to describe your PR, please do one of the following:

1. If this PR shall not be mentioned in the release notes, write "none" here.
2. If a brief note suffices, edit the title of this PR to be usable as entry in CHANGES.md, and write "see title" here (or if you have the required permissions, add the label release notes: use title to this PR and remove this section)
3. If a longer note is needed, just write it here, ideally following the general style used in that file

Further details

If necessary, provide further details down here.

[hulpke]

Is there a need to tag the synonym RadicalGroup immediately as obsolete? I have packages and private code that install methods, and there are publications out that explicitly refer to RadicalGroup. We can slowly change the princip[al use over, but I don't see a benefit in marking RadicalGroup for deletion.

[ThomasBreuer]

@hulpke Would it be sufficient to set the minimal level of InfoObsolete that triggers the message about the recommended function name to 2? (There seems to be confusion about the default level, see pull request #4654)

Actually, I see no reason to remove obsolete synonyms for names that are regarded as better, except if they are wrong. The situation is different for obsolete code, where one can argue that it would be a burden to maintain it further.

[hulpke]

As long as RadicalGroup continues to work and does not print warning or error messages I have no objection.

[wilfwilson]

When compiling the reference manual with this PR, there is a warning about an unresolved reference to RadicalGroup, which therefore needs to be updated to SolvableRadical. I'm not sure where the broken reference is.

#W WARNING: non resolved reference: rec(
  Attr := "RadicalGroup" )

[fingolfin]

It should still be documented! Normally when we rename things and make the old name obsolete, then we add an entry for it (including an index entry) to doc/ref/obsolete.xml, and I think that should be done here.

So I'd rather say:

Suggested change

	## 'RadicalGroup' was documented until version 4.11.1.
	## 'RadicalGroup' was renamed in GAP 4.12

[ThomasBreuer]

I can make this change.
But my understanding of the word "documented" is a positive one in the sense that one can rely on documented variables, and using undocumented variables can be risky. This was also the idea behind the (undocumented) function IsDocumentedWord; having index entries for deprecated variable names causes that the current implementation of this function does not fit to its intended meaning.

Concerning the sentence "Normally ...":
Currently we do not claim to have a complete list of name changes in the chapter called "Replaced and Removed Command Names" in the Reference Manual. The section about group actions lists "some examples of such name changes", and the section "Miscellaneous Name Changes or Removed Names" states that it lists "some further name changes". I think it would be better to have a complete list, and to state this --a topic for a new issue.

[ThomasBreuer]

@wilfwilson Thanks for the hint. This is very strange, in fact many instances of RadicalGroup were not replaced by the pull request; I do not understand what happened, but I will try to update the pull request in order to fix this problem.