Currently translated at 57.0% (506 of 887 strings)

This is a merger of three commits.

Currently translated at 57.1% (507 of 887 strings)

Currently translated at 100.0% (887 of 887 strings)

Gives a convenient way to check a player's password.

This entirely bypasses the SRP protocol, so should be used
with great care.

This function is not intended to be used
in-game, but solely by external protocols, where no
authentication of the minetest engine is provided, and
also only for protocols, in which the user already gives the
server the plaintext password.

Examples for good use are the classical http form, or irc,
an example for a bad use is a password change dialog inside
formspec.

Users should be aware that they lose the advantages of the SRP
protocol if they enter their passwords for servers outside the
normal entry box, like in in-game formspec menus,
or through irc /msg s,

This patch also fixes an auth.h mistake which has mixed up the
order of params inside the decode_srp_verifier_and_salt function.

Zeno-: Added errorstream message for invalid format when I committed

Note that the macro CHECK_FILE_ERR implements the code removed

Adds the particle option `collision_removal = bool`

Some particles are hard to use right now since they either go through
solid blocks (without collision detection), and with collision
detection enabled they (e.g. raindrops) would just stop dead on the
floor and sit there until they expire, or worse, scrape along a wall
or ceiling.

We can solve the problem by adding a boolean flag that tells the
particle to be removed if it ever collides with something. This will
make it easier to add rain that doesn't fall through your roof or stick
on the top of it. Or clouds and smoke that don't go through trees.

Particles that collide with this flag are marked expired
unconditionally, causing them to be treated like normal expired
particles and cleaned up normally.

Documentation is adjusted accordingly.

An added bonus of this patch is that particles can potentially collide
many times with nodes, and this reduces the amount of collisions to 1
(max), which may end up reducing particle load on the client.

This commit moves noise calculation to the functions where the noise is
actually required, increasing the separation of concerns and level of
interdependency for each mapgen method.  Valleys Mapgen is left unmodified.

- Convert instances of numeric literal doubles to floats
- Move dswitchint to a local variable now that being a member is unnecessary
- Improve const correctness
- Indentation fixes

MSVC and GCC evaluate parameters in right-to-left order, whereas Clang
evaluates in left-to-right order, and of course, an optimization could
leave the order of evaluation completely indeterminate.

This commit fixes all instances of the error by explicitly assigning the
results of expressions that use PseudoRandom::next() or range() to their
respective vector components.

The right-to-left evaluation behavior is preserved since Clang is much less
commonly used to compile Minetest than GCC and MSVC combined, and would
therefore cause the least harm.

- Add comment explaining why it exists
- Remove unused 'flooded' variable
- Rename shadowed variable
- Fix some code style

This commit condenses the above methods into a single implementation used by
V7, V5, Flat, Fractal, and Valleys mapgens and introduces MapgenBasic.

BiomeGen defines an interface that, given a set of BiomeParams, computes biomes
for a given area using the algorithm implemented by that specific BiomeGen.
This abstracts away the old system where each mapgen supplied the noises
required for biome generation.

We can remove the function in MtNativeActivity now
as it serves precisely that purpose: to tell irrlicht
that we handled the esc key.

TODO for later:
 * Perhaps try to find a more performant container than KeyList

Broken by b1965ac2.
This also prepares the begin and commit statements only once.

Fixes a bug where packet reordering made the server give the
client two peer ids instead of one. This in turn confused
reliable packet sending and made connecting to the server fail.

The client usually sends three packets at init: one "dummy"
packet consisting of two 0 bytes, and the init packet as well as
its legacy counterpart. The last one can be turned off since commit
af301831, but this is of lower
relevance for the bug. The relevant part here is that network
packet reorder (which is a normal occurence) can make the packets
reach the server in different order.

If reorder puts the dummy packet further behind, the following
would happen before the patch:

1. The server will get one of the init packets on channel 1 and
   assign the client a peer id, as the packet will have zero as
   peer id.

2. The server sends a CONTROLTYPE_SET_PEER_ID packet to inform
   the client of the peer id.

3. The next packet from the client will contain the peer id set by
   the server.

4. The server sets the m_has_sent_with_id member for the client's
   peer structure to true.

5. Now the dummy packet arrives. It has a peer id of zero, therefore
   the server searches whether it already has a peer id for the
   address the packet was sent from. The search fails because
   m_has_sent_with_id was set to true and the server only searched
   for peers with m_has_sent_with_id set to false.

6. In a working setup, the server would assign the dummy packet to
   the correct peer id. However the server instead now assigns a
   second peer id and peer structure to the peer, and assign the
   packet to that new peer.

7. In order to inform the peer of its peer id, the server sends a
   CONTROLTYPE_SET_PEER_ID command packet, reliably, to the peer.
   This packet uses the new peer id.

8. The client sends an ack to that packet, not with the new peer id
   but with the peer id sent in 2.

9. This packet reaches the server, but it drops the ACK as the peer
   id does not map to any un-ACK-ed packets with that seqnum. The
   same time, the server still waits for an ACK with the new peer
   id, which of course won't come. This causes the server to
   periodically re-try sending that packet, and the client ACKing it
   each time.

Steps 7-9 cause annoyances and erroneous output, but don't cause
the connection failure itself.
The actual mistake that causes the connection failure happens in 6:
The server does not assign the dummy packet to the correct peer, but
to a newly created one.
Therefore, all further packets sent by the client on channel 0 are
now buffered by the server as it waits for the dummy packet to reach
the peer, which of course doesn't happen as the server assigned
that packet to the second peer it created for the client.
This makes the connection code indefinitely buffer the
TOSERVER_CLIENT_READY packet, not passing it to higher level code,
which stalls the continuation of the further init process
indefinitely and causes the actual bug.

Maybe this can be caused by reordered init packets as well, the only
studied case was where network has reliably reordered the dummy
packet to get sent after the init packets.

The patch fixes the bug by not ignoring peers where
m_has_sent_with_id has been set anymore. The other changes of the
patch are just cleanups of unused methods and fields and additional
explanatory comments.

One could think of alternate ways to fix the bug:

* The client could simply take the new peer id and continue
  communicating with that. This is however worse than the fix as
  it requires the peer id set command to be sent reliably (which
  currently happens, but it cant be changed anymore). Also, such a
  change would require both server and client to be patched in order
  for the bug to be fixed, as right now the client ignores peer id
  set commands after the peer id is different from
  PEER_ID_INEXISTENT and the server requires modification too to
  change the peer id internally.
  And, most importantly, right now we guarantee higher level server
  code that the peer id for a certain peer does not change. This
  guarantee would have to be broken, and it would require much
  larger changes to the server than this patch means.

* One could stop sending the dummy packet. One may be unsure whether
  this is a good idea, as the meaning of the dummy packet is not
  known (it might be there for something important), and as it is
  possible that the init packets may cause this problem as well
  (although it may be possible too that they can't cause this).

Thanks to @auouYmous who had originally reported this bug and who
has helped patiently in finding its cause.

Partially reverts #3547
Infotext remains optional for objects, empty by default

Version 1.8.2 of irrlicht changed the way that IGUIStaticText::getTextHeight() works and since that release properly deals with newlines.

From irrlicht changes.txt for 1.8.2, "IGUIStaticText::getTextHeight returns now the correct height for texts with newlines even WordWrap is not set."

* Remove the copy from db::loadBlock by using a pointer to the destination
* cleanup db backend, the child backend doesn't have to set their functions as virtual

Commit 27ee8d89 forgot to add the paths
without ncursesw/ to the find_path() call