[alexeid]

In fxtemplates/ClockModels.xml the random local clock defines its mean-rate prior as MeanRRatePrior.c:s$(n), but the connect rule that adds it to the posterior (line 158) looks for MeanRRatePrior.c:$(n). The ids never match, so:

• any analysis built in BEAUti with a random local clock and an estimated clock rate (for example with tip dates) has no prior on meanClockRate, i.e. an improper flat prior;
• the prior doesn't appear in the Priors panel, so it can't be set by hand either.

This PR drops the stray s from the id rather than adding it to the rule: BEAUti reads the partition from the text after : (BeautiDoc.parsePartition), so c:s$(n) would file the prior under a partition called s<name>. BEAST 3's template already uses MeanRRatePrior.c:$(n), and BEAUti 3 does add the prior.

@rbouckaert, was the s deliberate? It came in with beast2 fdf94e3d (27 Apr 2012), which changed the id from c:$(n) to c:s$(n) but left the connect rule unchanged; the prior was a OneOnX then. If it was a way to switch that prior off, this PR changes the default on purpose: RLC analyses with an estimated rate get the template's Gamma(0.01, 100) (LogNormal(0, 8) with #111) instead of a flat prior.

Found while comparing BEAST 2.7.9 and BEAST 3 analyses built by hand in BEAUti (combination C15 in CompEvol/beast3-test: RSV2, random local clock, tip dates). The BEAST 2 XML had no mean-rate prior while the BEAST 3 one had Gamma(0.01, 100), giving a 0.4% difference in the clock rate.

Note for #111: it changes this prior's distribution on the adjacent lines but keeps the c:s$(n) id, so the prior stays disconnected there too. Whichever PR merges second needs a trivial rebase.

Second fix, same template: the rates prior RRatesPrior.c:s$(n). Its connect rule is generated from the same id, so it is added correctly at first. But .c:s$(n) doesn't match the .c:$(n) pattern in translatePartitionNames, so $(n) becomes the data partition's name rather than the clock's. After renaming the data partition, the rule looks for RRatesPrior.c:s<newname>; switching the clock away from the random local clock then leaves the old prior in the analysis, on clockrates that are no longer in the model. This PR drops that s too (BEAST 3 has the same bug: CompEvol/beast3#222), and updates the id SimpleClockModelTest expects.

Tested in BEAUti 2.7: with these changes the mean-rate prior is added to the analysis, and after renaming the data partition and switching to a strict clock no random local clock prior is left behind; without them, neither holds.