Adds new package.json config option with README explainer

[tonypconway]

FAO @notpushkin and @rviscomi

This PR adds a new option for configuring b-c-b using an object in package.json.

It adds the ability to log your config to the console.

It also adds the ability to set your target as "widely available on YYYY-MM-DD", which was requested by some framework folks.

Fixes #5 sufficiently that I would feel comfortable deprecating bl2bl when this is merged/released - the CLI approach feels unnecessary and I'll only seek to rebuild it if people are clamouring for it.

[notpushkin]

Alright, I think this should do the trick! I do have one more proposal, but if you want to unblock that Angular issue faster we can discuss it separately.

What if we merge targetYear and widelyAvailableOnDate into a single option? E.g.:

{
  "target": "2020",   //   →   2020-12-31 - last day of year
  "target": "2020-04",  //  →  2020-04-30 - last day of month
  "target": "2020-04-02", // → 2020-04-02 - fixed date
}

This is a bit trickier to implement, but I think it would be so much more streamlined. (On the other side, it would also remove any possibility of widelyAvailableOnDate and targetYearDate conflicting!)

---

As a sidenote, I’ve restructured the README a bit: https://gist.github.com/notpushkin/a809b6796773883a2820c6b1e50d3263

[tonypconway]

targetYear gets you Baseline Newly available features at the end of the specified year; widelyAvailableOnDate gets you whatever was Widely available on that date (i.e. features Newly available 30 months before that date). So collapsing it to a single property doesn't quite work. Documentation, articles about features and Web status.dev all talk about features as Widely available or situate them as part of "Baseline YYYY", so the properties are intended to respond to those two common ways of describing features. widelyAvailableOnDate is most likely to be used in cases like the Angular one where they want to give users a default that lines up with a specific version's release date, and users can override to something else if they need to. Does that make sense?

[tonypconway]

Perhaps renaming targetYear to baselineYear would make the distinction clearer.

[notpushkin]

Huh. Right. I guess really I haven’t had a lot of sleep lately haha!

Yeah, let’s go with baselineYear, and maybe widelyAvailableOn, without Date? I’ll update my README and send it tomorrow (as another PR, so that I don’t block you).

[tonypconway]

Right, just made what I think should be the final commit on this change - targetYear is now baselineYear everywhere except the eventual calls to BBM and I fixed some missing logic for correct config combinations. @notpushkin LMK if you're happy with it and I'll merge and release 👍

[notpushkin]

LGTM!

[tonypconway]

Squashing and merging - will run the date update in update-last-updated.js and bump the minor version in main before releasing. FYI, I'm expecting the publish workflow to fail again, unless you've made a change - I'll publish manually if it does fail.