✨ Standardize the components and theme creation API

[BattleCh1cken]

It might be a good idea to standardize the user facing component API so that we can guarantee component compatibility across themes.

I propose we do this with some sort of component constructor function. Here's an example:

// themes/linear/components/pro-con.typ
#let pro-con = make-pro-con((pros, cons)) => {

  table(
    // ...
  )
})

The make-pro-con function can just return another function that then gets assigned to the pro-con variable.

This would guarantee cohesion without need for more in depth code review, and would also allow the make-pro-con function to parse the arguments first, allowing for error handling. This might also help us close #28 , since it would allow us to handle incorrectly passed arguments in once place, instead of on a per-component basis.

The end goal would be to make switching themes guarantee to work without compiler errors.

[BattleCh1cken]

We could also consider doing something similar for entry functions. This would make defining a body-entry look like this:

#let body-entry = make-body-entry(ctx, body) => {
  // ...
})

This would have similar benefits to standardizing components, as we could better handle incorrectly passed in type parameters, which is one of the most common problems users need help with (also helping us resolve #28).

The main issue with this would be that we would have to standardize the parameters to type in some way, which might cut down on the customizeability of themes.