Optimize POD section handling in _parse_fh()

This is one of the hot spots that NYTProf points out for _parse_fh().
Avoiding the negative lookahead and the redundant regexp match for /^=cut/
yields a 10% speedup.
Only call _parse_version_expression() for lines that contain VERSION

This saves a method call for each source line that does not contain
'VERSION', yielding a whopping 30% speedup for _parse_fh().
Only compile $PKG_REGEXP and $VERS_REGEXP once

These regexps are static and so can benefit from the /o modifier.
Profiling shows that this gives a 15% speedup for _parse_fh().
Fix t/metadata.t failure under Cygwin

This fixes RT #78376.
Test package_versions_from_directory with regard to case-sensitivity
Portability fix-ups for new_from_module()

This fixes test failures on VMS, and resolves RT #76030.
Bump version to 1.0.10 and update Changes
Properly handle BOMs at the beginning of the file

This applies to new_from_file and new_from_module, but not new_from_handle.

This fixes RT #78434.
POD tweaks
A couple of tests about commented versions
Don't collect "=cut" at the end of a POD section
Don't skip lines beginning by # in POD

They are only comments in code.
"defined $x ? $x : undef" better written as "$x"
Be stricter about which =XXX are POD keywords
Detect POD sections like perl would

perl considers that a POD section begins with a line that starts by "=X",
X being any alphabetic character, and ends by "=cut" followed by a
non-alphabetic character. This commit makes Module::Metadata follow this
strategy.

Note that there's still a gotcha : "=X" must be a statement to start a POD
section. This means that in

    my $x
    =pod
    ;

'pod' is treated as a bareword, hence is compiled to either a string
literal or a function call depending on whether a pod() sub has been
previously declared in the current package. Module::Metadata cannot do
anything about this situation.

This commit partially reverts the previous commit a4aafbc2.
Test for __(?:DATA|END)__ in the "code" section of the loop

If the line is =cut, then it can't possibly be __DATA__ or __END__.
Remove warning for when modules don't do $VERSION = eval $VERSION.

In a non-trivial number of cases this will be triggered on code one
doesn't have any control over, and thus can't really fix--the verbosity
therefore doesn't actually provide any benefit to the user. In the
original use case (Module::Build::ModuleInfo) this sort of warning makes
good sense as a sanity check for authors. It has no place in a general
purpose library, though.

... not to mention the bloody thing was an unless/else block. Seriously?
And the warning did not at all communicate what the actual problem was.
Bad UX all around.
Do the (dev) release dance
apeiron is an idiot
remove other spurious warning