MapblockMeshGenerator: Use more verbose member names

[Desour]

• Goal of the PR: The code in content_mapblock.cpp is kinda hard to read due to heavy use of member variables that look like local stack variables (and quite non-specific variable names, like origin or color). All in all, it's hard to find out where something is defined or written to. Sometimes there are also name clashes (i.e. tile in getTile).
• What this PR does:
  • Member vars were made private and const if possible.
  • Member vars are grouped into structs.
  • Member vars (or the structs they're in) start with m_.
• This is a maintanance / code quality PR, without functional changes.

To do

This PR is a Ready for Review.

How to test

• Skim through and make sure everything works the same as before.
  (The diff is large, but very simple.)

[sfan5]

@numberZero do you have an opinion on this?

[numberZero]

Member vars were made private and const if possible.

👍

Member vars (or the structs they're in) start with m_.

👎 That adds more clutter than help IMO.

Member vars are grouped into structs.

For drawtype-specific stuff, that’s better than currently. But maybe it is possible to split the class instead?

[numberZero]

Also, meshmanip and enable_mesh_cache are specific to mesh nodes

[Desour]

Also, meshmanip and enable_mesh_cache are specific to mesh nodes

They are not specific for the current mesh node though.
The structs are only valid if currently the specific drawtype is drawn.

Member vars (or the structs they're in) start with m_.

-1 That adds more clutter than help IMO.

I guess this also goes down to personal preference. I'll remove the m_ then if nobody else favours it.
Btw. how about cliquid for "current liquid" (and the same for plant, ...)?

Member vars are grouped into structs.

For drawtype-specific stuff, that’s better than currently. But maybe it is possible to split the class instead?

Splitting it would be good at some point I guess. But idk how to make it well, and rebasing would be harder.

[numberZero]

They are not specific for the current mesh node though.
The structs are only valid if currently the specific drawtype is drawn.

Okay.

how about cliquid

cur_liquid would be better IMO.

But idk how to make it well

Neither I do, so nvm. That is for another PR.

[Desour]

Done.

[numberZero]

LGTM

[Desour]

Rebased.

[Desour]

Rebased, and checked that the rebase went correctly.

Also added 2 commits, see commit descriptions.