Drop Option.FromBoolean in favour of a SelectMany overload for the pair `bool`, `Option<T>`

[FreeApophis]

I know, hear me out:

This means instead of

Option.FromBoolean(boolean, something);

you would write

from _ in boolean
select something;

this get especially interesting if you have a combination like this real example:

private static Option<IFormFile> GetFormFile(Request request)
  => request.HasFormContentType
    ? request.Form.Files.FirstOrNone()
    : Option<IFormFile>.None;

With FromBoolean:

private static Option<IFormFile> GetFormFile(Request request)
  => Option.FromBoolean(request.HasFormContentType, request.Form.Files.FirstOrNone()).SelectMany(Identity);

With SelectMany:

private static Option<IFormFile> GetFormFile(Request request)
  => from _ in request.HasFormContentType
     from file in `request.Form.Files.FirstOrNone()`
     select file;

[bash]

I have to say: I don't hate it :)
The chainability when used method-style is a nice advantage over Option.FromBoolean.

Some notes:

1. Unfortunately, StyleCop (using our configuration) complains about the use of _:

   SA1312: Variable '_' should begin with lower-case letter
   

2. Do we want to allow SelectMany the other way around?

   from item in option
   from _ in boolean
   select something

   That's basically the same as a where, right?
   I could imagine that we support it, but add an analyzer against it with two fixes:
   • swap the two from clauses
   • convert the boolean from to a where
3. Do we want to allow to consecutive boolean froms? That's the same as an AND.
4. What parameter does the selector take? a bool that's always true or should it take a Unit?

An alternative to Option.FromBoolean and the SelectMany approach would be to have something like Rust's then:

// Overload 1: takes value
Option<_> a = boolean.Then(something);
// Overload 2: takes func<value>
Option<_> b = boolean.Then(() => something);
// Overload 3: takes func<option>
Option<_> c = boolean.Then(() => option);

What I like about this is that there's no parameter to discard :)

[FreeApophis]

1. is sad, but we have that problem in other places too.
2. well the main argument against this feature is the increasing number of SelectMany overloads. We probably should discuss how to proceed with them in general. We had the decision in RangeExtensions.SelectMany causes confusing compiler errors #677 to only add SelectMany extensions in the Extension name space but we never added all the SelectMany combinations which would be possible. The Where is a good argument, if it would be possible to always change the order we probably should only have the Where.
3. Probably not as it it would indeed just model the && operator.
4. I thought of Unit, it is also the way Option.FromBoolean works.
5. I like boolean.Then too, it might be easier to discover than the SelectMany too. I don't think the Extensions on bool will pose a problem.

[bash]

1. We could add a DiagnosticSuppressor to Funcky.Analyzers (or even Funcky.BuiltinAnalyzers?) that disables SA1312 for this specific case.
2. The main usability issue that we discussed in RangeExtensions.SelectMany causes confusing compiler errors #677 is already there, so I think I am okay with adding more overloads.
3. 👍🏼
4. 👍🏼
5. Would we want the SelectMany overload and Then to both exist or should we choose one over the other? I have a slight preference for Then only as it is doesn't require discarding a unit :)

[bash]

Removing / obsoleting Option.FromBoolean also means that we should update OptionSomeWhereToFromBooleanRefactoring.