core(lightwallet): Deprecate 'performance-budget' audit / add 'resource-budget' audit

[khempenius]

• Deprecates performance-budget audit
  • Will not appear in the HTML report, but will remain in the JSON
  • Warning and log message inform user that they should switch to using resource-budget
• Adds resource-budget audit
  • This audit is identical to the existing performance-budget audit.
  • Appears in HTML report & JSON.

Motivation
As part of supporting timing budgets, the functionality of the performance-budget audit is being renamed to resource-budget. (And timing-budget is being added as a separate audit.) However, for the time being, performance-budget is being left in codebase for sake of smooth deprecation.

Related Issues/PRs
#8917

[patrickhulce]

sheesh has our checked-in boilerplate really ballooned

a file and id rename turns into 900 changes 😆

[patrickhulce]

performance-budget is being left in codebase for sake of smooth deprecation

Oh sorry I just meant to bring it up for discussion I'm not 100% convinced we should duplicate it yet :D

Anyone else have thoughts here? If it weren't treated specially as part of the report UI, I'd be all for just nuking it and doing the rename but the specialness of this audit makes it worth consideration at least IMO :)

[patrickhulce]

Discussing this in LH sync today my understanding is that we'd prefer to just leave the ID as-is performance-budget and live with the minor inconsistency. We still keep the label/string changes here to reflect that they're only addressing resources. We can announce that we intend to rename this to resource-budget in a future breaking change and can expose this also under resource-budget in a future non-breaking version, but we wanted to leave more warning time on this one.

@khempenius how does that sound to you?

If anyone had a different understanding from the meeting please speak up :)

[connorjclark]

I'll voice an opinion no one else shared: If we are going to make this breaking change, and a programmatic deprecation warning is not possible (as Paul mentioned), I think it best to do it as early as possible to minimize total pain (huh, I guess I'm a utilitarian)