Add `bit_width` functions

Add the following functions in `src/util.hpp`:

    template<typename T> inline std::size_t bit_width();
    template<typename T> inline std::size_t bit_width(T x);

These functions compute the size, in bits, of a type or value, providing
a convenient and self-documenting name for the underlying expression,
`sizeof(…) * std::numeric_limits<unsigned char>::digits`.

This commit adds two additional header `#include` directives in
`src/util.hpp`. The newly included headers are as follows:

  - `<cstddef>`, for `std::size_t`; and
  - `<limits>`, for `std::numeric_limits`.

At first, I obtained the bit width of a byte using the C preprocessor
macro `CHAR_BIT`, defined in the C standard library header `<climits>`,
rather than using `std::numeric_limits<unsigned char>::digits`, but I
subsequently switched to using `std::numeric_limits` per Soliton’s
recommendation at 2014-03-17 21:36Z in the `#wesnoth-dev` IRC channel on
the freenode IRC network (<irc://chat.freenode.net/%23wesnoth-dev>).
Have `bit_width(x)` take `x` by reference.

In `src/util.hpp`, change the following function signature:

    template<typename T> inline std::size_t bit_width(T x);

To the following function signature:

    template<typename T> inline std::size_t bit_width(const T& x);

This avoids needing to call `T`’s copy-constructor, which could be
annoying.
Add `count_ones` function

Add the following function in `src/util.hpp`:

    template<typename N> inline unsigned int count_ones(N n);

This function returns the quantity of `1` bits in `n` — i.e., `n`’s
population count.
Add `count_leading_zeros` function

Add the following function in `src/util.hpp`:

    template<typename N> inline unsigned int count_leading_zeros(N n);

This function returns the quantity of leading `0` bits in `n`.
Add `count_leading_ones` function

Add the following function in `src/util.hpp`:

    template<typename N> inline unsigned int count_leading_ones(N n);

This function returns the quantity of leading `1` bits in `n`.
Merge branch '8573/util/count-leading-ones/1' of https://github.com/8680-wesnoth/wesnoth into codepoint_count
Improve byte_size_from_utf8_first()

The count_leading_ones function by 8680 improves speed and readability
of this function which parses UTF-8 characters.
Mark Wesnoth not high-resolution capable

Greatly improves performance on retina devices
Remove references to unused flag ENABLE_OPENMP_SUPPORT

Not available in clang, gcc support unstable in versions available in
Xcode. Defaults to no
Compile Lua with OS X options

Avoids some warnings, more secure
optimize minimap.cpp

moved 2 preferences::.. calls out of the loop so that we just call it once.

the following is especialy true on large maps, all results are recorded from a msvc 2010 release build, and recorded with the msvc 2010 sampling Profiler.

these calls are less expensive than the final scale_surface_sharp call at the end of the funcion. But if you assume the scale_surface_sharp woudn't be there, then they'd use a major part (~50%) of the cputime of get_minimap.

i also tested replacing scale_surface_sharp at the end of the function with scale_surface. Here are the results:
tested on LotI Mp Map (part of LotI addon) which has a size 200x200 with fog but no shroud, no logs, ingame debug mode enabled (the :debug wesnoth-console command).
the image on the upper middle is made with scale_surface the other two are made with scale_surface_sharp.
The down-left Image are the profiler results from the scale_surface version of get_minimap, the down-right are from the scale_surface_sharp version. The record was started shortly before a moving so the record only  shows the cputime during moving. Also the content of this commit is used in those testings.
http://i.imgur.com/YETVuNq.png
the profiler shows that during movements (with fog) more than 50% of the cputime of wesnoth is spend in scale_surface_sharp for get_minimap, and i personaly think differences in the minimap are not worth that. But there are different opinions and thats why i didn't change it yet, but i still propose replacing the last call

minimap = scale_surface_sharp(minimap,
		static_cast<int>(minimap->w * ratio), static_cast<int>(minimap->h * ratio));

with something like: 

if(map.w() > 100 || map.h() > 100)
{
minimap = scale_surface(minimap,
		static_cast<int>(minimap->w * ratio), static_cast<int>(minimap->h * ratio));
}
else
{
minimap = scale_surface_sharp(minimap,
		static_cast<int>(minimap->w * ratio), static_cast<int>(minimap->h * ratio));
}
note, that the 100 is choosen rather randomly.
If that's a problem with msvc then i propose wrapping it in a #if.
I have heared that we will be able to do scaling with hardware acceleration later (around september), but i don't see how thats a reason to not do this until then.
Coward MAI: remove unnecessary condition

ai_helper.movefull_stopunit takes care of this internally.
Return guardian MAI: remove unnecessary condition

We can never get to this point in the code if the unit does not have
moves.
MAIs: test for unit equality directly, not via coordinates
Add unicode_cast to wrap utils::X_to_Y() functions
Use unicode_cast
Add a ctor to ttexture which loads the texture from a file.
Fix a memory leak in the previous commit.
Merge branch 'master' of github.com:wesnoth/wesnoth
Fix bug #21759

Removed duplicate code that caused timer to be refreshed an additional
time if time runs out. The usual refreshing in
playmp_controller::after_human_turn is already called in this case as
well (after turn ends). The duplicate code gave the bonuses before the
turn ended, and after that the turn was ended (giving turn bonus again)
only if there was no random seed incoming from the server.

Conflicts:
	changelog