lib: clear error when a dependency's library was not in the install plan

[hamishmack]

Fixes the opaque error reported in #1379.

Problem

When a package is unplanned (not in the cabal install plan) but has been given overrides, depending on it failed with an unhelpful attribute 'library' missing error pointing deep inside packages.<x>.components.library. dependToLib (lib/default.nix) had a comment noting an assert would be nicer "but there is currently no good way to get the name of the dependency when it is not in the plan".

Fix

A package value carries its identifier at the top level (builder/hspkg-builder.nix), and an unplanned package simply lacks a library under components (allComponent filters to buildable && planned). So the name is reachable. dependToLib now, in the missing-library branch only, throws a clear message naming the package and explaining it was not in the install plan (add it to the plan, or drop the override).

• Only the previously-failing branch changes; when library is present the result is byte-identical.
• No added strictness: the normal path already forces d.components to read .library, so d.components ? library costs nothing.

Tests

Added test/unit.nix cases exercising the real haskellLib.dependToLib: library resolves, sublib (no components) passes through, and an unplanned package throws. Full unit.tests suite eval → [] (pass) under ghc9124. Verified out of band that the real throw reads:

haskell.nix: the library of package 'my-dep' is not available because it was not in the install plan. This usually means the package was given overrides (e.g. via modules / packages.my-dep) but is not part of the cabal plan, so none of its components were planned. Add it to the project's dependencies (so it appears in the plan), or remove the override.

A normal project is unaffected (the normal path is unchanged); I did not run a full project eval (needs plan-nix IFD + network).

Follow-up (out of scope)

The plan also floated stubbing the throw at component-assembly time so direct hsPkgs.<pkg>.components.library access gives the same message; this PR keeps the change minimal and targeted at the reported dependency path.

Closes #1379.