partly revert e454252f2

there are multiple reasons why i think this should be reverted:
1) this wasn't tested enough, especialy we don't even know, whether all mainline campaigns are compatible
(this can be easily fixed, but only if one know which campaigns are effected which requires testing)
2) after renaming remove_from_carryover_on_leaders_loss to remove_from_carryover_on_defeat it sounds wrong that this can result in removing units on victory.
3) this seemed to break many UMC addons.

Note that this only removes one check for defeat_condition before [endlevel].
Especialy if for example side 1 gets defeated by defeat_condition in turn 1 but the game still goes on due to multiple other non defeated sides, but then the game ends with [endlevel] result=victory in turn 2, the units will be removed from carryover (unless specified otherwise)
This was also the pre 1.11.13 behaviour.
Also note that we cannot remove the 'defeated' side in case of [endlevel]result=victory, becasue [endlevel] doesn't sepcify which sides have victory/defeat.
Balancing tweaks

Limited number of bats Khrakrahs may have at a time, moved the dwarves
closer to the map edge where possible, and gave the Berserkers
predefined traits to prevent them from being quick (except one on hard).
Made the undead spawns require Jevyan to be alive
geography.cfg: correct wmllint spelling for Castelfranc and Rumyr

These towns were misspelled in their encyclopedia entries, compared to
the Wesnoth map. All of the instances in my UMC collection follow the map
spellings, so I am not leaving the incorrect spelling as an alternative.

Also, there were spelling rules for both "Memog" and Melmog on separate
lines. No reason to keep the mistake around.
wmllint: remove -f --future option

Going back through wmllint's history, it turns out that there apparently
haven't been any "experimental conversions" since 1.4. Especially since
some new switches have been added recently, the clutter makes it no longer
worth keeping around.

A comment notes the option's disappearance, in case anyone is interested
in recreating experimental conversions again.
wmllint: remove -p --progress option

This option is pretty similar in effect to -v -v. Particularly now that
some new switches have been added recently, the clutter makes it no
longer worth keeping around.

A comment notes the option's disappearance, in case anyone wonders what
happened to it or how to get the same functionality.
Merge pull request #258 from gfgtdf/check_victory_3

partly revert e454252f2
LoW: remove an unneeded comment block
wmllint: split introduction into labeled sections for clarity

Also, the top paragraphs, aimed at the core developers, have been moved to
the bottom, to get to the information key to general users.
wmlscope: import glob for Windows shell

The Windows cmd shell will not expand a globbed argument by default, in
fact it will make the argument invalid. Importing and utilizing the glob
module is needed for x-platform.

Globbing is especially important for breaking up the subtree, so wmlscope
doesn't give off "more than one resource/definition is visible here"
errors.
wmltools: cite define locations when "more than one definition" is visible

When "more than one resource" is visible, wmlscope tells you where they
are.  Now it will do the same for macro definitions.
wmltools: fix wmlscope crash in collection of unresolved macro calls

While testing wmlscope without including data/core, which guarantees lots
of "unresolved" references, I got a crash pointing to this line with the
traceback: "NameError: global name 'args' is not defined".

At first, I thought the crash might have been caused by my splitting out
parse_macroref into its own function, several months ago. However, the
line is at the wrong indentation level for those "args" to be the variable
referenced here. So what "args" might have been intended?

After tracking down the commit that added "args=args" to this line, I've
concluded that this was simply a mistake. ESR isn't around to ask anymore,
but if a macro was never defined, or is not called correctly, what "args"
could be relevant?
Update RELEASE_NOTES
Update changelog
updated Lithuanian translation
fixed changelog formatting
updated Slovak translation
wmltools GUI: remove -f and -p wmllint options, add -m
Goto MAI: fix bug causing errors for unreachable goal hexes

This includes hexes occupied by an enemy unit.
wmltools: split campaigns/add-ons into separate subtrees for wmlscope

The problem: wmlscope assigns each file to a directory-based subtree, and
assumes that it is visible to every other file in that subtree. The intent
is that each campaign (or add-on of another type) will be in its own
subtree.

However, wmlscope/wmltools has derived these subtrees based on what
arguments get passed to wmlscope, rather than checking whether campaigns
have actually been split out. For instance, invoking wmlscope with
"../data/core ../data/campaigns <userdata>/data/add-ons" will cause
wmlscope to see three subtrees, one of which consists of all mainline
campaigns and another that includes all the user's add-ons. This leads to
many spurious "more than one definition/resource is visible here" errors.

A wildcard like "data/campaigns/*" would be expanded to all the individual
campaign directories. However, the wmlscope user might not know that they
should do that. Also, until the glob module was imported recently, globbing
did not work in the Windows cmd shell.

The solution: declare "campaigns" and "add-ons" to be roots, and check for
their presence in the directory names. If indicated, split out the
subdirectories into their own subtrees. Since it is possible that the user
may have moved, copied, or drafted campaigns/add-ons to another folder
that isn't following Wesnoth convention, also check for that.