The persons who wrote this dummy.conf file did so to work around a limitation of the network-scripts configuration found for example in CentOS 7: there's no way to run an arbitrary command to help create a virtual interface (like it's possible in the Debian-mostly-used interfaces file with a pre-up entry). If somebody gives a clue on a simple method to run such a script (ie: not having to create a full new ifup-dummy script) I'll be happy to edit my answer.
The dummy module, has a default option numdummies=1 (the option can be found with modinfo -p dummy). That means when the dummy module is loaded for the first time, it will also auto-create (on the initial network namespace) a dummy interface. The default naming is dummy+first available integer, so dummy0.
What the modprobe setting does is to ensure that when the dummy module is loaded (as OP told, it's loaded at boot) , this implicit dummy0 interface will be immediately renamed ethdummy1, and --ignore-install is there to prevent an infinite loop because it would just keep replacing loading of the dummy module by... loading of the dummy module.
This allows the ifcfg-ethdummy1 configuration to work correctly: the expected interface is found as if it was an usual ethernet interface.
It's possible to continue this way (despite very awkward), by editing the dummy.conf file like this (I put the link parameters in the natural order by the way):
install dummy /sbin/modprobe --ignore-install dummy numdummies=2; /sbin/ip link set dev dummy0 name ethdummy1; /sbin/ip link set dev dummy1 name ethdummy2
Adding the module option numdummies=2 created two dummy interface dummy0 and dummy1, and they were "immediately" renamed to their final names ethdummy1 and ethdummy2. Now you can add a corresponding configuration file ifcfg-ethdummy2.
If you just added a new configuration and don't want to reboot or lose interfaces, you can add the interface manually so the ifup command will still succeed after:
ip link add ethdummy2 type dummy
Why do I find the work-around in dummy.conf awkward? Because this won't work for the same system (eg CentOS 7) running in a container: the interfaces are always added to the initial network namespace, so the container will never see them (and also usually a container is prevented to explicitly load a module, even if a container can still indirectly trigger the loading, for example by using ip link add type dummy).
Personally i'd rather use for dummy.conf this: options numdummies=0: create no interface by default, and deal with it as needed. At least the result would be consistant when using or not a container.
I didn't either find that NetworkManager supports natively dummy interfaces, but at least it's scriptable. You can check the solutions offered in this link: Dummy interface on RHEL. They add a script for NetworkManager, or use systemd's instantiation of a service to create an interface by starting it with the chosen name.
If you're later using a Debian-like distribution, then this is easily solved by using pre-up ip link add ethdummy2 type dummy 2>/dev/null || : in the interfaces' stanza.
