standardize zines (books, not ammo)

[Jerimee]

Summary

SUMMARY: Content "abstract for magazines w appropriate dimensions"

Purpose of change

By making an abstract of magazines we simplify the json and the ease with which we can apply universal updates to magazines.

Magazines now all have the same height and width. They also all have longest side as needed by #40186

Describe the solution

• The abstract already existed in classes/book.json. I moved it to items/books/abstract.json in a previous PR.
• I moved schematics_generic and book_martial to classes/book.json abstract.json
• I created an abstract "book_comic" to distinguish comic dimensions from typical magazine dimensions
• I also added longest_side to 4 books in archery and barter, and update the dimension for those, providing an isbn13 comment to show what IRL book I based the dimensions off of.
• make abstract "book_nonf_manual_tpl"

Describe alternatives you've considered

While there is a standard magazine size, not every magazine conforms to it perfectly. There probably are 3 or 4 most common formats, and then ones unique to a given periodical. Those can be accounted but adding the custom values to the individual magazines or, better yet, creating alternative zine dimension abstracts in classes/book.json and then associating the zines with those formats.

Should all softcover books have one or both of these flags? "flags": [ "TINDER", "FLAMMABLE" ],

Many of the books had thematic coloring - a book about wine will be red and the milk cookbook was white - I changed those to conform to the color key in the doc. Hopefully that was the right thing to do.

Additional context

I have a much more involved PR #37377 that provides a structure of "cascading" abstracts for books, along with cascading SUS item groups. It has now been approved; some of the changes associated with this PR are resolving conflicts to conform with the other.

[Jerimee]

I resolved conflicts between this and #37377 - just fyi

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Please do not 'bump' or comment on this issue unless you are actively working on it. Stale issues, and stale issues that are closed are still considered.

[kevingranade]

I keep putting off reviewing this, sorry about that.
Here's the thing, this kind of hierarchy of inheritance arguably makes edits easier (I actually disagree, it makes one easy kind of edit easier, and it makes other more difficult edits harder), but it makes reading and understanding the data much more difficult. I've tried to review this PR at least five times now, and I keep getting frustrated and giving up because this is too complicated, you have to cross-reference multiple entries to find out the values of a single book, and then if you want to look at balance, you have to repeat that across multiple different books, and essentially recreate the level of redundancy you're trying to eliminate.
I need to write up some guidelines for data inheritance, but it's getting grossly overused already in areas like this and getting really unwieldy.
There are two situations where copy-from should be used in mainline.

1. Two things are nearly identical variants of each other.
2. A group of entities always (not almost always, always) shares some set of properties, then one or two levels of abstracts can set up a very shallow and narrow hierarchy.