[CR]Add "calories" field to it_comest

[Coolthulhu]

As discussed in #13857
Conflicts with #14597

This is mostly to allow starting the migration, there are no in-game effects here.

Calorie field is used only if the nutrition field is unset (or set to a negative value - not used in game, because nutr was unsigned before).
I assumed 1 unit of nutrition is ~8.7 kcal because:

• Average survivor consumes 1 nutrition per 5 minutes
• There are 12 * 24 = 288 hunger "ticks" per day
• I assumed average active person consumes 2500 kcal/day
• 2500 / 288 ~= 8.7

Both nutrition and calorie fields are kept. They are accessed through get_nutrition() and get_calories(). Made nutr field private.

[kevingranade]

Friends are bad, can we just replace this with a constructor? (I'm assuming that's why it's needed.)

[Coolthulhu]

I went with friend class because currently all itypes use only the default constructor and because itype (the base class) already has Item_factory as a friend. It looked like a convention, so I tried not to break it.

I could add a setter or make the field public as it was before. Constructor alone would work now, but it would require either a setter or public field later if we wanted to add mod override for individual item fields (as opposed to overriding the entire item at once).

[kevingranade]

It's best to stick with a constructor and make the object immutable. If we want to selectively override fields it's better to replace the object with a new instance with the new values. Setters would suggest to people that the fields can be modified at runtime (which has happened in the past and caused hard to find bugs).

[kevingranade]

However I'm looking at merging this, I'll follow up with a PR of my own doing what I'm suggesting, and we can discuss the general issue there, this is a long term thing, and the nutrition thing is short-term.

[kevingranade]

You know, I'm wrong, friendship on a factory is perfectly reasonable.

[kevingranade]

Seems like a great idea, why CR?