markdown fixes, html tweaks, and two emoji consistency fixes

[SpiritAxolotl]

Most notable non-emoji changes:

• Markdown formatting
  • Changed all emphases with asterisks (*text*) to underscores (_text_)
  • Removed slashes from the end of links
  • Trimmed the whitespace a bit in code snippets
• Replaced all instances of master with main
• Fixed incorrectly hyperlinked things
• Clarified a few commands
  • yarn prepublish isn't a command, but yarn prepublishOnly was
  • git clone -b master {repo} was shortened to git clone {repo} (again, master doesn't exist)
• Changed a few vars to lets
• Cleaned up the markdown in FOLDERS.md
  • Added more whitespace to make most of the columns align better in the editor
  • Put the Top level, Second, and Files column contents in code snippets (fixes the incorrect markdown emphasis)
• Re-added the correct emojis after being changed in commit 65f4a5d

Emoji changes:

• The eyebrows of :imp: (\u1f47f) are now consistent with that of :smiling-imp: (\u1f608)
• The color of the blue heart is now consistent with other blue objects (resolves #70)

Running yarn prepublishOnly didn't prompt me to change the version number, otherwise I would have made it 15.2.1

Last thing: I had to install jq with brew in order to even use that yarn command, so should I put add it as an extra step for macOS users in CONTRIBUTING.md?

[SpiritAxolotl]

gonna make this up-to-date soon

[SpiritAxolotl]

I also realize that it might be better for me to separate this pr into two prs, one for the general fixes and another for the emoji tweaks. Should I do that? @jdecked

[SpiritAxolotl]

activity going well it seems

[jdecked]

activity going well it seems

I understand that having a PR sit for a while is frustrating. Committing one mega-PR that changes 47 files with a combo of explained, unexplained, and linting preference changes is not an efficient way to contribute to OSS (or, really, to most projects used by many people). Generally PRs like these go to the bottom of most OSS maintainers' to-do lists because reviewing them takes much more coaching/feedback than the average maintainer has time for, even if the changes themselves aren't complicated: you're effectively handing the maintainer a pile of coloured bricks and asking them to sort the bricks for you before adding them to the building. Some OSS projects have the bandwidth to coach people into making higher efficiency contributions, but not all (or even most).

Twemoji typically follows a once a year release cadence in line with Unicode – typically with a few patches in between. We often batch the "please redesign XYZ emoji" issue requests into one patch or (less frequently) the next minor/major release. Patches come out when we have time for non-critical issues: unlike some other OSS projects, Twemoji isn't anyone's day job.

Now that I've explained this to you, hopefully you realize the sarcasm wasn't necessary.

[SpiritAxolotl]

I do wish there was an acknowledgement of this pr but it wasn't a reason for me to be sassy about it. sorry about that.

I'll close this pr and split it into one for markdown and one for the actual emoji changes at some point in the future. I don't understand why the new emojis were written to by the github action in commit 94c7591 when I pulled from the upstream. hopefully that won't happen next time when I fork it from the upstream originally.

again, really sorry for the sarcasm, and thank you for doing god's work with this project.