My opinion - I would refrain from any "execute all" or "read all" permissions. They are risky. I would operate on a least privilege model and create roles to access specific objects on an as needed basis.
Admin access is dependent on what you mean. Do you mean admin to the instance OR admin to the database? if it is the instance, then sysadmin is the role you are talking about, but I'd use that role VERY sparingly. if it is at the database level, db_owner is the role you are looking for, but again, I'd use that role VERY sparingly. Admin access (sysadmin or db_owner) gives the end user a LOT of permissions that you may not be thinking about like dropping the database or shutting down the instance.
Next, if your permission list is exactly what you want, I would re-do it a bit. I would work with a more descript permission set. What I mean is since permission set 2 and 3 have some overlap, I would make permission set 2 to be JUST reading from tables and views and have permission set 3 just be executing stored procedures. Then when you assign people to the database, you put them in permissions set 3 and permissions set 2 to cover what you suggested for permissions set 2. The reason for this is in the future when you create a 4th permissions set for reading data only (which is useful for things like reporting users), you have that permission set already created as number 2.
Now, as for the "all" part of permission set 2 and 3, I would strongly encourage you to avoid those "all" permissions. The reason being that it is easy to set up, but hard to maintain. Lets say in 5 years someone makes a stored procedure that should only be run after hours due to the duration and resource usage. Since it should only be run after hours, you also want to restrict it so that only a small number of users can run it which should reduce the chance it gets run during company uptime. That becomes a pain if you need to modify all existing objects so that the stored procedure can only be run by the small group of people.
What I would recommend is you work with a least privilege model. So if you have a finance team and an HR team (for example), they likely shouldn't have too much overlap in what they can run or read from the database. And if you have HR data in the database, you may be required to restrict that.
Now if you choose to ignore the above and grant permissions across the board like you suggested, you could do this by creating a new role called something like "ExecuteAll" and granting EXECUTE on the schema (or schemas if you have more than 1) to that role. Next create a role called "SelectAll" and granting SELECT on the schema (or schemas if you have more than 1). Next, you add users to the new roles. For permission set 3, they get added to ExecuteAll. For permission set 2, they get added to ExecuteAll and SelectAll. A user can be a member of multiple roles. I do not recommend going this route as it will very likely lead to additional overhead in the future.
A 3rd option, the least secure option mind you and it assumes that your permission sets listed above are a complete list of permissions on the database, would be to grant execute on the schema to public. This would allow any user with an account on the database to execute any stored procedure. But this is also the least secure option and the biggest pain in the butt to maintain so I would avoid this as much as you possibly can.