Allow greater use of LOCATION in API

[DanRStevens]

A number of built in methods take separate x and y values, while Unit coordinates are only ever returned as LOCATION structs. Perhaps we should provide helper methods to help paper over the difference.

We could perhaps provide the reverse of the MkXY macro, which instead takes a LOCATION and converts it to the x and y pairs. That maybe wouldn't be very pretty though.

We could also provide overloads or new methods to paper over the difference. Example:

void CenterViewOn(enum PlayerNum playerNum, const LOCATION& location) {
	Player[playerNum].CenterViewOn(location.x, location.y);
}

[Brett208]

I don't currently use the MkXY macro. I would probably prefer overloads to the macro. Are there class instance functions that we are looking to overload as well? If so, I'm not sure that is so easy and might be a use case for the macro?

[DanRStevens]

We could add free-standing functions with enough parameters to delegate to member function calls. I suspect that's where most of the convenience can be added.

Indeed, we would not be able to provide new member functions for the exported classes. At best we could use macros to adapt the parameters. In that case, the macros would expand one parameter into multiple parameters. For an example of that in use, see the AutoSize(array) macro, which expands a parameter into an array pointer and an array size.

I also don't use the MkXY macro. We probably could provide methods to replace some of those macros. This is the inverse case where multiple parameters are combined into one new object. This could be implemented as an inline factory function.

Related is the NumberOf(array) macro, which repeats the argument multiple times to perform a calculation. In some cases the result may need to be constexpr. This can now be replaced by a constexpr function. We can do away with that macro.