Tracking bug for cabal.project semantics

There isn't any documentation for `cabal.project`, and it mostly does what people expect, except when it doesn't. So there are two problems: (1) there needs to be documentation saying exactly what `cabal.project` is supposed to do, and (2) the behavior needs to be set to match.

Here are the bugs:

- [ ] #3719 - How to specify options for ALL transitive dependencies (not just inplace or local packages)
- [ ] #3681 - How to pass `--extra-include-dirs` when building `HsOpenSsl`? (I think the root cause is HsOpenSsl is not inplace, configurations don't apply to it.)
- [ ] #3579 - Package field applies even to NON inplace packages (So, maybe the semantics are that if you put it in `packages` it applies even to non-inplace thing?)
- [x] #3442 - Profiling doesn't work
- [ ] #3334 - Top-level flags to `new-build` apply to local packages, NOT inplace packages
- [ ] #2997 - People expect top-level flags to apply to dependencies, but they don't actually
- [ ] #3883 - BUT `program-options` apply to ALL packages
- [ ] #3891 - See @phadej's comment lower down; `ghc-options` needs to be partitioned into "affects hashing" and "doesn't affect hashing" flags.

General patterns I'm seeing:
- People are used to saying `cabal install FLAGS` and having FLAGS apply to all the dependencies which are being built. (#3719, #2997, #3681) `new-build` works differently: it NEVER applies the flags to transitive dependencies. This is actually what you want, because if the flags applies to all transitive dependencies, you would end up rebuilding the world every time you specified, e.g., a different `--extra-include-dirs`. But it's slightly unintuitive behavior, and worth warning about.
- Even if that's not what you want by default, there should be a way to specify an operation on all transitive dependencies (a case when you really do want to rebuild the world.) (#3334)
- There is a distinction between a local package (one which you listed in `packages`) and an inplace package (any package which transitively depends on a local package). For example, in Cabal itself, `hackage-security` is NOT a local package, but it is an inplace package (as it depends on Cabal). The semantics for many operations are murky on whether or not they apply to inplace or local.
- There is not a way to specify a per-package operation ONLY on inplace/local packages; it always applies to all copies of the package (#3579)

CC @dcoutts

Start with the `cabal.project` semantics and `new-build` behavior described in this issue, then read the linked issues #3719, #3681, #3579, #3334, #2997, #3883, and #3891. The work is done when the intended semantics are documented and the related behavior matches that agreed specification.

Written by the indexing model from the issue text.