Utility functions have been moved out to Utils. Minor opportunity to
drop the header where not needed.

This used to be necessary to fetch the DataLayout, but isn't anymore.

Note that the version of getValueProfDataFromInst that returns bool
has been "deprecated" since:

  commit 1e15371dd8843dfc52b9435afaa133997c1773d8
  Author: Mingming Liu <mingmingl@google.com>
  Date:   Mon Apr 1 15:14:49 2024 -0700

- With PGO, indirect call edges are constructed using value profiles, and the profile address is mapped to a function's PGO name. The PGO name is computed using a functions linkage before LTO internalization or global promotion.
- With ThinLTO, local functions [could be
promoted](https://github.com/llvm/llvm-project/blob/2663d2cb9c9361f0b234c40a0f50c7ba0748eb26/llvm/lib/Transforms/Utils/FunctionImportUtils.cpp#L288) to have external linkage; and with
[full](https://github.com/llvm/llvm-project/blob/2663d2cb9c9361f0b234c40a0f50c7ba0748eb26/llvm/lib/LTO/LTO.cpp#L1328)
or
[thin](https://github.com/llvm/llvm-project/blob/2663d2cb9c9361f0b234c40a0f50c7ba0748eb26/llvm/lib/LTO/LTO.cpp#L448)
LTO, global functions could be internalized. Edge construction should use a function's PGO name before its linkage is updated.

The `BlockFrequency` class abstracts `uint64_t` frequency values. Use it
more consistently in various APIs and disable implicit conversion to
make usage more consistent and explicit.

- Use `BlockFrequency Freq` parameter for `setBlockFreq`,
`getProfileCountFromFreq` and `setBlockFreqAndScale` functions.
- Return `BlockFrequency` in `getEntryFreq()` functions.
- While on it change some `const BlockFrequency& Freq` parameters to
plain `BlockFreqency Freq`.
- Mark `BlockFrequency(uint64_t)` constructor as explicit.
- Add missing `BlockFrequency::operator!=`.
- Remove `uint64_t BlockFreqency::getMaxFrequency()`.
- Add `BlockFrequency BlockFrequency::max()` function.

Mostly removing includes of InitializePasses.h and Pass.h in
passes that no longer has support for the legacy PM.

Don't fetch BFI if the function has no entry count. Peculiarly,
the implementation was already doing this for the (no longer
existing) legacy PM implementation, but the same principle applies
to the new pass manager. The only reason why the new PM doesn't
have LazyBFI is that with the new pass manager all passes are
lazy.

This improves compile-time for non-PGO builds.

These were used to abstract between NewPM and LegacyPM. Now that
the LegacyPM implementation is gone, we can fetch the analyses
directly from the FAM.