Implement [p]trivia info and add DESCRIPTION to trivia schema

[Kreusada]

Description of the changes

Adds a new command, [p]trivia info <category>, as well as a new DESCRIPTION key to the trivia list schema.
DESCRIPTION is an optional key, just like AUTHOR. DESCRIPTION will appear only in [p]trivia info as of now.

The idea came from @japandotorg in the Red server. If this PR is accepted and merged, #5565 will need to be updated to include this new key.

Fixes #3978

Don't be alarmed by the number of files changed, this PR is also adding DESCRIPTION keys to existing core lists and there are only a few files where code has been changed

Have the changes in this PR been tested?

Yes

[Jackenmen]

The example given for the description of logo trivia in the guide kind of makes me want to show the description in the startup message (as sort of an introduction) but that wouldn't really work when multiple trivia lists are selected, oh well...

[Jackenmen]

For me personally I wouldn't see that as an issue

Feel free to go ahead with it then. I don't really have any suggestions on how this should look, do whatever you think will look good I guess.

Unless, an argument were to be added similar to [p]serverinfo, where you can customise the detail shown in the command, maybe defaulting to True (show descriptions), but have the False option to view the list how we would view them as it stands.

Probably not worth it, let's just assume nobody cares about seeing a compact version of the category list.

[Jackenmen]

#5565 has been merged, this requires some changes now

[Jackenmen]

Hi, just reminding you that this PR is waiting on the addition of descriptions to the [p]trivia list command with proper pagification that would replace the current comma-separated list.

[Kreusada]

Hi, just reminding you that this PR is waiting on the addition of descriptions to the [p]trivia list command with proper pagification that would replace the current comma-separated list.

I've managed a quick implementation through using the get_trivia_list() method. However, this isn't ideal at all as it requires opening each trivia list file through the iteration, making the command slow to produce output. It may be worth caching the trivia lists on cog load so that the dictionaries are then always available without opening their files. I thought that may have been out of scope for this PR though, I'd be interested to hear your opinion on this.

[Jackenmen]

I've managed a quick implementation through using the get_trivia_list() method. However, this isn't ideal at all as it requires opening each trivia list file through the iteration, making the command slow to produce output

I see, I didn't realize this will become a concern here. While I do think we should pursue this, I don't want to make this PR's approval contingent on this change. I went ahead and added missing descriptions for recently added trivias, moved the length check to schema, and made some other small chore changes. Thanks for contributing!