feat: add event, location, and date frontmatter

[calebdw]

Hello!

Closes #312

This PR adds fields for the presentation event, location, and date---these are optional fields but are common frontmatter elements, particularly if the presentation is for a larger conference / event.

Example:

---
title: How to Think Like a Designer
sub_title: It's easier than you think
event: Laracon US 2024
location: Dallas, TX
date: 2024-08-28
author: Jack McDade
---

Thanks!

P.S., I'm really new to Rust so sorry if I didn't do thing in the idiomatic Rust way!

[calebdw]

@mfontanini, the concern about documentation can be solved a few different ways---the best way is to version the docs so a user could see the docs for master, v0.8, v0.7, etc. by a version select on the docs site.

An easy fix in the near term though is to simply update .github/workflows/docs.yaml to only deploy new docs when a new version tag is pushed instead of on every push to master (I can easily include this change in this PR if you like).

I can remove the docs if you wish, but I do have several concerns about doing so:

1. It increases the maintenance burden at release time---it is much easier to update the docs with the PRs that introduced new features instead of trying to wait until ready to release and then put together all the docs
2. New features have the potential to be forgotten about and missed. The mermaid theme docs were missed and so I added them in #314
3. It is very difficult for nightly users to discover new features / options. They would need to parse through source code instead of just being able to read the docs on the master branch. This actually happened to me (I like to be on the bleeding edge of things), I only found out about the mermaid theme options because I was digging through the source code trying to figure out if it was possible to update the background color---it would have been much easier if the docs were at least updated on master

Just let me know how you'd like to move forward!

[mfontanini]

the best way is to version the docs so a user could see the docs for master, v0.8, v0.7, etc. by a version select on the docs site.

Yeah, I'm aware of this solution but I have limited time to spend on this project and this would be very low on my priority list. I'm sure however this would work it would be annoying though as I'll have to backport doc changes to all versions if it's a docs "fix" (e.g. a missing feature or something that's wrong) rather than a new feature being included.

An easy fix in the near term though is to simply update .github/workflows/docs.yaml to only deploy new docs when a new version tag is pushed instead of on every push to master (I can easily include this change in this PR if you like).

Then if I find an issue or something missing in the current docs (e.g. your mermaid theme change), I'll need to manually remove all docs that only apply to nightly and not the latest release, generate the docs by hand, and push them which is a non negligible amount of work and very easy to mess up (e.g. end up including changes for nightly on the latest release's docs).

It increases the maintenance burden at release time

I don't really mind this tho :). I can actually sit down and add/change/clean up everything all at once.

New features have the potential to be forgotten about and missed

Fair but this is on me, I should have made a note to myself.

It is very difficult for nightly users to discover new features / options

Fair, but I think in its current form the solution is pretty bad as well. I obviously don't have numbers on this but I imagine almost nobody (maybe you're the 0.1%) will clone the repo and manually generate the docs just to see what's new on nightly.

[calebdw]

Alrighty :+1:, I removed the doc changes

[mfontanini]

Thanks!

[calebdw]

Thank you sir!