Convert OperatingSystem documentation to Markdown - #5710

Headers could be aligned and the extra whitespace from the end removed.

Making references to external libraries actual links is a good idea, but I'm not sure can we count on BuiltIn.html being on the same directory as the docs of this library. When the docs are hosted online that is
the case, but if someone downloads the doc or views this doc via an editor, the link won't work.

Safer alternatives:

• Link to the online version with a full URL like [Regexp Escape](https:///...#Regexp%20Escape). This has a problem that the URL is pretty long (I needed to cut it in this comment as well) making the source look a bit bad. It may not matter much in general, but if it does, creating a reference target and then using just [Regexp Escape] in the actual documentation would help.
• Just format the keyword name and make only BuiltIn a link that points to online documentation. Also this requires a longish URL, but this time a reference target for [BuiltIn] could be used also in other places. A drawback is that users would need to find the actual referenced keyword themselves. A direct link would probably be better, even if it would require multiple reference targets.
• Don't do any linking. We haven't had links earlier so not adding links now is obviously fine as well. I have been thinking that adding links like this would be a good idea, though.

The pathlib.Path part could probably be code formatted with backticks. I think the table of contents and everything else will work even if a header has formatting, but that would need to be tested.

I'm not entirely sure what is the best place for documenting arguments and return values. I guess it to some extend depends on the keyword, but perhaps it would be best to always have them in the beginning after the "short doc" as in the example below. That's the approach we've used with other libraries.

def example(arg: int) -> int:
    """This is the short doc.

    Args:
        arg: Argument doc.

    Returns:
        Retrun value doc.

    The main keyword doc.
    """

These examples must have the *** Test Cases *** header and a test case name to be syntax highlighted correctly. In most cases using the name of the documented keyword as the test case name is fine. If there are needs for multiple slightly different tests, they should be based based on what they demonstrate.

A link to docs about the accepted error handles could be added. We have just added it to a String library keyword that allow encoded values. See here:

👍 for replacing the old way to show results with Should Be Equal. An alternative would be showing the result with a comment after the keyword call like we did with some BuiltIn keywords, but actually validating the return value makes it easier for us to test these examples.

A problem here is that on Windows you get my\path instead of my/path so the example won't pass. We could only add a note about that, but I think it's better to change the test so that it uses the built-in variable ${/} that is either / or \, depending on the operating system. In practice that would mean using my${/}pathinstead of my/path.

There's the same problem with / and \ as with the previous example. In this case using ${/} doesn't work, because it would be replaced with \ on Windows before evaluating the inline Python expression and something like 'base\other' isn't valid. That can be fixed easily by using raw strings like r'base${/}other', but I'm slightly worried this gets rather technical. I don't see any other easy solution so perhaps that's fine.

Oh, this keyword already had a note about the ´/and` issue. I'm fine copying the note (minus the home directory part) to the above keywords instead of using ${/}.

Cool that you added a test for this! We probably should make this generic so that it tests all standard libraries. Leaving it like it is now is obviously fine in the context of this PR.