rfc: add :osxfuse dependency to support binary or homebrew installs

add :osxfuse symbolic dependency
add ConflictsWithFuseForOsx requirement for osxfuse/fuse4x

**reasons:**
- presently, osxfuse will fail to link the bottle files if the binary install is present (conflicting files), but will not fail a build as a dependency (perhaps this is a bug, but is resolved in this pr)
- if the binary distribution is installed, a user would be forced to uninstall just to use any brew fuse formula (and perform osxfuse postinstall steps)
- some apps check/require the official Fuse for OSX installation. #28298
- PR discussed/suggested in #26211

initial commit includes only Dependency+ConflictsWithFuseForOsx to start a discussion on this feature
i have all osxfuse dependent formulas working locally with both binary/brew fuse installs
can commit some/all formula updates later (so it doesn't swamp brewbot)

**non-fatal issues:**
formula.include references:
afflib: `-I#{Formula["osxfuse"].include}/osxfuse`
- compiles, but probably works as the makefile scans the standard /usr/local/include already
- builds without this directive, only useful if HOMEBREW_PREFIX is not /usr/local

ext2fuse: `-I#{HOMEBREW_PREFIX}/opt/osxfuse/include/osxfuse/fuse`
- fails to compile, quick fix would be to add `-I/usr/local/include/osxfuse/fuse` to cover both cases
- wouldn't expect formula devs to cover both cases long-term

?? live with the quick fix for now?
?- don't see any existing patterns that would yield the system vs formula locations of include/lib
-- (PythonDependency.)which_python is the best poor example I've found
--- ranger.rb calls `PythonDependency.new.which_python`
--- many other formula copy/paste the which_python method (all in science/osgeo4mac taps)

**question:**
does `depends_on :osxfuse` negate the ability to bottle?
...if so, just remove bottle directive from those that have?
If you'd like more clarification on what you should do it's OK to ask but it currently feels like you're just ignoring what I'm saying because you disagree.