Identified with modernize-loop-convert.

Identified with modernize-use-using.

Identified with readability-redundant-typename.

Previously a "opt<std::optional<std::string>>>" would fail to
parse/would attempt to parse option value as argument.

This PR passes the VFS down to `llvm::cl` functions so that they don't
assume the real file system.

Reapplying now that buildbot has picked up the new configuration
that does not use -treat-scalable-fixed-error-as-warning.

-----

This removes the `LLVM_ENABLE_STRICT_FIXED_SIZE_VECTORS` cmake option
and the `-treat-scalable-fixed-error-as-warning` opt flag.

We stopped treating these as warnings by default a long time ago
(62f09d788f9fc540db12f3cfa2f98760071fca96), so I don't think it makes
sense to retain these options at this point. Accessing a scalable
TypeSize as fixed should always result in an error.

This reverts commit 8f59a946740bf8dbe2574b33eaa431fde3ce9204.

Failed on clang-aarch64-sve-vls-2stage, which still uses the option.

This removes the `LLVM_ENABLE_STRICT_FIXED_SIZE_VECTORS` cmake option
and the `-treat-scalable-fixed-error-as-warning` opt flag.

We stopped treating these as warnings by default a long time ago
(62f09d788f9fc540db12f3cfa2f98760071fca96), so I don't think it makes
sense to retain these options at this point. Accessing a scalable
TypeSize as fixed should always result in an error.

## Purpose

This patch is one in a series of code-mods that annotate LLVM’s public
interface for export. This patch annotates the `llvm::cl::opt` explicit
template instantiations for export with `LLVM_TEMPLATE_ABI` and
`LLVM_EXPORT_TEMPLATE`. This annotation currently has no meaningful
impact on the LLVM build; however, it is a prerequisite to support an
LLVM Windows DLL (shared library) build.

## Background

This effort is tracked in #109483. Additional context is provided in
[this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307),
and documentation for `LLVM_ABI` and related annotations is found in the
LLVM repo
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst).

Annotating the `llvm::cl::opt` template instances for DLL export was not
straight-forward like other explicit template instances that have
already been annotated. Annotating them as documented
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst#templates)
results in link errors when building a Windows DLL using MSVC.

## Overview 
There are two specific issues that appear when exporting the
`llvm::cl::opt` templates and compiling a Windows DLL with MSVC:
1. We cannot export `opt<std::string>`. This is because MSVC exports all
ancestor classes when exporting an instantiated template class. Since
one of `opt`'s ancestor classes is its type argument (via
`opt_storage`), it is an ancestor of `std::string`. Therefore, if we
export `opt<std::string>` from the LLVM DLL, MSVC forces
`std::basic_string` to also be exported. This leads to duplicate symbol
errors and generally seems like a bad idea. Compiling with `clang-cl`
does not exhibit this behavior.
2. The `opt` template instances other than `opt<bool>` get optimized out
because they are not referenced in the TU (`opt<bool>` actually is). It
is unclear exactly why MSVC optimizes these template instances away, but
`clang-cl` does not. Adding explicit references to the instantiated
`opt` template classes' vtables via implicit virtual destructor forces
MSVC to export them.

## Validation
Windows with MSVC
Windows with Clang