Issue title: OJS Reset Article Permissions action is unclear
 Issue body: In journal settings we have a button that says "Reset article permissions".

The description is:

> Reset Article Permissions
> Copyright statement and license information will be permanently attached to published content, ensuring that this data will not change in the case of a journal changing policies for new submissions. To reset stored permissions information already attached to published content, use the button below.

Many journal managers (and me) think that this means they can change all article permissions with one bulk command to the settings they have defined in the same form. We have had similar situations and have seen questions concerning this in the forum. 

However, what the Reset button actually does is that it just removes all the attached permissions from all articles.

I am not a native speaker, but for me "reset" means something else than "remove" or "delete". I, and many others, expect that "reset" means resetting the permissions to the given default values. 

I suggest that we:

1. Change the language there and use the word "Delete" or "Remove":

> **Delete** all article permissions

> "To **remove** stored permissions information already attached to published content, use the button below."

AND

2. Add a secondary button that allows journals to bulk set all published article permissions to match the defaults given in the settings.

> Reset all article permissions using the default values

I think that we definitely need to do at least number 1.










 Comments: 
 Comment 0: @ajnyga, I agree with your assessment of the problem. I'm not sure two buttons are justified, though -- what about making the button behave as you expect (to reset all permissions on published content)? If someone wants to clear permissions and leave them empty, they can empty the journal settings first and use the button.
 Comment 1: Sounds good.
 Comment 2: @asmecher 
ojs: https://github.com/pkp/ojs/pull/2353
lib: https://github.com/pkp/pkp-lib/pull/4651

Noticed that a close issue (https://github.com/pkp/pkp-lib/issues/1466) has been dealt with recently so tagging @NateWr here as well. 

I think that the new description text in master branch does not need any revision? The desrciption there mentions "current default settings" and that is actually what has been fixed now with this pr.

edit: tests passed
 Comment 3: @NateWr, may I leave this one with you?
 Comment 4: :+1: merged. Thanks @ajnyga!

@asmecher since this fix _will_ go out with 3.2, should I assign it to the 3.2 milestone now that it's closed, so that we know which milestone it contributed to?
 Comment 5: One small thing to consider left here. 

With the license and copyright holder you can now empty the fields by leaving the default settings blank and running reset. However, with the copyright year you have a radio button selection. If you have already chosen one of the two options, then you can not reset the articles to have no copyright year. You can only reset the value to one of the two options available...

Not sure if that is necessarely an issue though
 Comment 6: I believe this is correct. When resetting, it will use the `copyrightYearBasis` setting for the context, which will set the year to either the article's publication date or the issue's publication date.

I notice that the `copyrightYearBasis` property is `nullable` and has no default value. In such a case that would lead to an `assert(false)` in `Articl38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5_getContextLicenseFieldValue()`. Perhaps that's something that should be addressed, by preventing it from being nullable and setting a default value to `issue`.

If you agree I'll open a  new issue.
 Comment 7: yes I noticed that when I was doing this pr, see https://github.com/pkp/pkp-lib/issues/4654

And I guess that fixes this minor issue as well. I am thinking a (maybe non-existing) situation where a journal wants to *remove* all copyright year data from all articles. Now they can only choose between the two available options.

 Comment 8: Excellent, it's already filed! I'll drop a quick note in about how to do this in the schema system.

> Now they can only choose between the two available options.

That sounds reasonable but maybe a separate use-case. I like that we've aligned things here along the "reset" use case. That they can delete is ok, but if they need full deletion, maybe it's best to make them jump through a few hoops. It seems like it would be something to discourage except under extraordinary circumstances.
 Comment 9: yes agreed, even resetting all article permissions is something that has to be a bit difficult to do.
 Comment 10: @NateWr:

> since this fix will go out with 3.2, should I assign it to the 3.2 milestone now that it's closed, so that we know which milestone it contributed to?

Yes, I've done that!
 Comment 11: Thanks, @ajnyga, this is great! (And thanks for tackling the review, @NateWr.)
{'source': 'GithubIssues', 'repo_name_with_owner': 'pkp/pkp-lib', 'issue_id': 422618704, 'repo_stars': 267.0}