Standardize and Document BscPlugin Event Timing (Potential Breaking Change)

Problem

It's often confusing to know when a BscPlugin will be run. For example, for provideFile, we actually want to be the last plugin to run during provideFile, because we want other plugins to be able to provide the values when possible, and fall back to ours. So in that case, we would register the bscPlugin to listen to the afterProvideFile, and since bscPlugin is the first registered plugin, it will effectively act as the "last" plugin to operate during the provideFile event.

Open Questions

• Should the BscPlugin always operate this way, or are there certain events where it should run earlier? Or later?
• Are there any events where the current order is critical to existing plugin behavior?

Proposal

• Establish a standard for when the BscPlugin should be run relative to other plugins for each event.
• Document this standard, as well as any exceptions (with justifications).
• Update the codebase to ensure consistency with this standard.

Breaking Change

This will most likely be a breaking change since we may end up changing when certain BscPlugin events are fired. We should consider the impact to plugin authors and communicate this in release notes.

Tasks

• Discuss and agree on the standard for BscPlugin event timing.
• Document the standard and any exceptions.
• Update implementation and tests as needed.
• Communicate breaking changes to plugin authors.