LocalBuildInfo fields are poorly named or designed

## Problems
### `with` fields

These field names have the prefix `with`:
- `withPrograms :: ProgramConfiguration`
- `withPackageDB :: PackageDBStack`
- `withVanillaLib :: Bool`
- `withProfLib :: Bool`
- `withSharedLib :: Bool`
- `withDynExe :: Bool`
- `withProfExe :: Bool`
- `withProfLibDetail :: ProfDetailLevel`
- `withProfExeDetail :: ProfDetailLevel`
- `withOptimization :: OptimisationLevel`
- `withDebugInfo :: DebugInfoLevel`
- `withGHCiLib :: Bool`

In usual Haskell parlance, `with` indicates a function in continuation passing style, but these are simple accessors.
### Singular/Plural

These fields refer to executables, libraries, or package databases in the singular, which is incorrect because we handle multiple of each simultaneously:
- `withPackageDB :: PackageDBStack`
- `withVanillaLib :: Bool`
- `withProfLib :: Bool`
- `withSharedLib :: Bool`
- `withDynExe :: Bool`
- `withProfExe :: Bool`
- `withProfLibDetail :: ProfDetailLevel`
- `withProfExeDetail :: ProfDetailLevel`
### Duplicated fields

We have
- `withProfLib :: Bool` and `withProfLibDetail :: ProfDetailLevel`
- `withProfExe :: Bool` and `withProfExeDetail :: ProfDetailLevel`

when `libProfiling :: Maybe ProfDetailLevel` and `exeProfiling :: Maybe ProfDetailLevel` would be more idiomatic.
### Essentially-unused fields

The program configuration in `withPrograms :: ProgramConfiguration` can't actually be serialized. Also, the programs in use can and often are reconfigured after the package is configured! Package configuration and program configuration are separate issues.
## Proposed Solutions
1. Rename the `with`-prefixed fields.
2. Add fields `libProfiling :: Maybe ProfDetailLevel` and `exeProfiling :: Maybe ProfDetailLevel`.
3. Split `LocalBuildInfo` into `PackageConfig` (which would have most of the same fields as `LocalBuildInfo`) and a separate `ProgramConfiguration`.
## Compatibility

I can add deprecated accessors for all the renamed and removed fields. However, code which assigns those fields will have to change.

Splitting up `LocalBuildInfo` internally does not need to affect external code because we can always reconstruct a `LocalBuildInfo` for legacy interfaces.