More readme fixes

[AbdulrhmnGhanem]

• Fixes ogx360 readme images are broken #421
• Fixes dropbot-40-channel-HV-switching-board readme images #424
• Fixes GOSH-Board_UGM readme images #426
• Fixes uduino readme images #428
• Closes Emojis support in project description #431

[kasbah]

Can we add some integration (or maybe even unit tests!?) for this functionality?

[AbdulrhmnGhanem]

I added e2e tests for them and will move them to the processor later as part of #448.

[kasbah]

Looks good, minor suggestions again. Please also correct the spelling mistakes in your commit messages.

[kasbah]

I pushed some refactoring to this branch because I was working of off the review branch and I couldn't resist. Should have caught this in earlier reviews but linkifyKitspaceYaml had some issues around mutation of the input and also doing so off in an async way after the function returned. Wouldn't have caused any issues yet but it's a bit of a footgun down the line.

[AbdulrhmnGhanem]

mutation of the input and also doing so off in an async way after the function returned.

Do you mean this line?

 Object.keys(kitspaceYaml.multi).forEach(async subProject => {
   linkifiedKitspaceYaml.multi[subProject] = await renderProjectSummary(kitspaceYaml.multi[subProject])
 })

[kasbah]

Yeah, that creates an async function for each key in the yaml but doesn't await or return it. Just before that you had

const linkifiedKitspaceYaml = kitspaceYaml

Which references the same object and then you mutate it with the async functions.

The scenario where this could have caused problems is if we had another sub-task that shares the kitspaceYaml with writeKitspaceYaml and wanted to use the summary for something where it really shouldn't be html.

Overall I'm wondering if this is really the right place to render the description. Shouldn't the frontend just handle it? It's fine for now... let's not spend time on it but something to think about for the future.

[kasbah]

s/format in project reamde & summary/format in project readme & summary/