Unable to enable core dumps

[AdamDorwart]

Describe the bug
The documentation says

Core dumps are disabled by default. If you absolutely require them, you can enable them by using unix.Setrlimit to set RLIMIT_CORE to an appropriate value.

However the DisableCoreDumps calls unix.Setrlimit(unix.RLIMIT_CORE, &unix.Rlimit{Cur: 0, Max: 0}) which sets the hard limit at 0. Any future calls to unix.Setrlimit that attempt to raise Cur/Max will result in an operation not permitted. This also applies to any children processes (exec.Command).

Either the library should only set the soft limit or disabling coredumps should be configurable.

To Reproduce
Steps to reproduce the behaviour:

1. Use memguard
2. Attempt a unix.Setrlimit(unix.RLIMIT_CORE, &unix.Rlimit{Cur: 1, Max: 1})

[joda-work]

code dump disabeling code seems to exists since v0.20.0 (7 years ago), would be great to have an option to disable that behavior (at least for influxdata/telegraf this is unexpected to have no option to disable the behavior or documentation).

[joda-work]

@AdamDorwart Do you think it would make sense to add an environment variable or parameter to optionally disable the (go global) initial disabeling of core dumps?
Here is the code line that is executed on every gobinary startup that includes memguard: core/init.go#L8

[AdamDorwart]

I'm guessing an environment variable might be a security risk for those relying on this currently to disable coredumps. An internal parameter might make more sense. This isn't configurable but it's what I did for my purposes:

func init() {
	// Get current limits first
	var rLimit unix.Rlimit
	if err := unix.Getrlimit(unix.RLIMIT_CORE, &rLimit); err != nil {
		panic(fmt.Errorf("could not get rlimit: %v", err))
	}

	// Set only the soft limit to 0, keep the hard limit unchanged
	rLimit.Cur = 0
	if err := unix.Setrlimit(unix.RLIMIT_CORE, &rLimit); err != nil {
		panic(fmt.Errorf("could not set rlimit: %v", err))
	}
}