Please note, this is only the initial version of the PR, intended for
internal discussion / augmentation before being turned into a real
("draft") PR, for wider discussion / voting.

As some classes already have a .code method, and this would be a collision.

Specifically for the announcement of Raku

Add specific mention of Rosetta Code

Also fix some erroneous backslashes

We need new material, that's the important thing.  Of course that will
wind up in a repo.

FWIW, I mentioned a new repo because I thought we had lost the repo with
Zoffix' departure.

And remove "because of a name change", because that's what this SWOT
analysis is all about anyway, so redundant

This reverts commit 62c083d.

* Make sure we have a release where .raku is specified, but .perl is
  not yet deprecated, to allow migration time before receiving the
  deprecation warning
* Tweak the mechanism for module's .perl fallback
* Add a missing heading

After carefully considering @AlexDaniel review, #108, and
[some IRC chatting](https://colabti.org/irclogger/irclogger_log/perl6-dev?date=2019-09-26#l179),
I would like to propose to remove the part about `.t` deprecation. I do
it with a some regret as this proposal would postpone the voting if
accepted, but:

1. Tools currently supporting TAP are used to this extension. We can't ask all of them to produce the deprecation message for Raku only.
2. This would allow a user to choose the extension more suitable to the tools he/she is using and even up to his personal preferences.
3. In a way, this conform to TIMTOWTDI.

Clarify the situation with .t extension

Added more info on how editors should add support for
extensions raku test extensions. Based on these conversations:

* #109
* #108 (comment)

Please tweak if my understanding is incorrect.

For me personally it's easier when I see some actual examples.

Based on #108 (comment)

> I can say that problem-solving issues that attempt to revisit
> decisions made in the renaming PR will need to make a very
> compelling case to avoid being dismissed out of hand.

Moreover, inclusion of extensions in the PR was done with the idea
that tools will only have to add new extensions once.

Surely one can expand it even more, but that's enough for me.

I'm not sure what's the exact idea behind that sentence, but for
example I wouldn't want to see deprecation messages any time I run
code that uses some commonly used but unmaintained module. I think
this can be ironed out later.