This matches how ld.bfd works in practice; this fixes
https://github.com/mstorsjo/llvm-mingw/issues/305.
Adding a test for the new lib name combination that this allows, but
also adding a few negative tests for combinations that aren't
matched when -static is specified (because this change in itself
didn't break any of the existing tests either).
The logic in how ld.bfd looks for various libraries based on
an -l<libname> argument is rather complex; the
ldemul_open_dynamic_archive function looks for various combinations:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/emultempl/pep.em;h=e68d1e69f17ad73af065b6bed19ae89ded913172;hb=b51c2fec1da205ea3e7354cbb3e253018d64873c#l2066
This function is only called if looking for dynamic libraries
(i.e. if -static wasn't specified):
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/ldfile.c;h=731ae5f7aedcf921bd36a1b32a3e0f5bfa189071;hb=b51c2fec1da205ea3e7354cbb3e253018d64873c#l365
However even this function is skipped, it still looks for libraries
in the form of "lib<libname>.a" (this is what lld did before):
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/ldfile.c;h=731ae5f7aedcf921bd36a1b32a3e0f5bfa189071;hb=b51c2fec1da205ea3e7354cbb3e253018d64873c#l440
But it also calls a format specific function called
ldemul_find_potential_libraries, which for PE targets looks for
files named "<libname>.lib":
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/emultempl/pep.em;h=e68d1e69f17ad73af065b6bed19ae89ded913172;hb=b51c2fec1da205ea3e7354cbb3e253018d64873c#l2175