Prepare for version 3?

[stertooy]

• Document the recently added inputs build-needed-pkgs, build-suggested-pkgs and build-extensions
• Update action versions in README
• Validate inputs when relevant (like in run-pkg-tests)
• Made indendation consistent (2 spaces per level)

Perhaps we should also rename the CONFIGLAGS input before releasing a new version, but that can happen in a separate PR.

[fingolfin]

What are the breaking changes in here that require going from v2 to v3?

[fingolfin]

(Of course PR #15 contains a potentially breaking change...)

[stertooy]

What are the breaking changes in here that require going from v2 to v3?

None in this PR. I mostly felt like bumping to v3 might be appropriate now that 19a857b has been merged, since the default behaviour of the action has changed. But strictly speaking that shouldn't be "breaking" either, unless some workflow somewhere somehow relies on a particular dependency not being built. It might increase the time for CI tests, though, e.g. if a package has semigroups as a suggested package.

[fingolfin]

@stertooy I have not yet tagged v3 -- perhaps we should first get #15 in?

[stertooy]

@fingolfin Seems good to me. Do we also merge #13 and/or rename CONFIGFLAGS to configflags before tagging v3?

[fingolfin]

Yes, also #13. I see you approved both PRs, so I'll just merge them now

[fingolfin]

... and done, and I tagged v3