[dv/chip] LC_CTRL related chip level coverage

- [ ] [cindy] lc_otp_vendor_test_i/o: Move to connectivity test, tied off in open source chip level test.
---> Check if block level checked output from CSR, check if connectivity is done in chip level.
Block level check here: https://github.com/lowRISC/opentitan/blob/master/hw/ip/lc_ctrl/dv/env/lc_ctrl_scoreboard.sv#L163

- [ ] lc_otp_program_o.count/program: sparsely encoded. So some of the toggle values are unreachable.
But since we are changing build-seeds to generate different encoding pattern, it is very hard to find the unreachables on the fly.
Are we comfortable to exclude the entire outputs?
- [ ] otp_lc_data_i.state/count: same issue as above
- [x] [cindy] lc_otp_program_i.err: We have a testbench, but it only forces the value to be 1. Will fix it to release the force.
- [ ] kmac_data_i.error: No test currently cover this scenario. Test issue: https://github.com/lowRISC/opentitan/issues/16069
- [ ] [cindy] otp_manuf_state_i: design constant, other values can be excluded.
- [x] [cindy] hw_rev_o.chip_rev/chip_gen: design constant, can just check connectivity.

FYI @msfschaffner @sriyerg

Start with the lc_ctrl scoreboard at hw/ip/lc_ctrl/dv/env/lc_ctrl_scoreboard.sv#L163 and review each unchecked coverage item. Check the linked issue 16069 for the kmac_data_i.error test context. Done means resolving or documenting the listed connectivity, unreachable-value, and missing-scenario coverage decisions.

Written by the indexing model from the issue text.