Add support for custom checkboxes and radios

[eladlevy]

Implemented custom checkboxes and radios mode as discussed in 3047.
Includes tests and documentation

[jquense]

Looks great! @taion how do you feel about adding the custom prop vs a different set of components?

[jquense]

I think may make sense to put custom on the Context object below with controlId, that way when using the individual components you don't need to explicitly pass custom to the input and label

[eladlevy]

Great feedback! I wasn't aware of the Context option. This helps to reduce code and makes the customize render option a lot easier to use.

[jquense]

I would shorten this all to something like:

Custom checkbox and radio styles are achieved with a resourceful use of the :checked selector and ::after psuedo elements, but are Structurally similar to the default FormCheck. By default the checked and indeterminate icons use embedded svg icons from Open Iconic...

[taion]

It seems like this is slightly easier than adding e.g. <CustomFormCheck.Input>. That said this seems almost like something bsPrefix can handle, though.

[taion]

gah i clicked the wrong button

i meant if we had support for bsPrefix from FormCheck cascading down into FormCheck.Input, then had some special-ish (?) logic to also add custom-checkbox or whatever if the bsPrefix is custom-control.

is that too magical? probably? (though i like having that sort of bsPrefix semantics)

in which case i think a custom prop is good

[eladlevy]

@taion hmm I can try overriding bsPrefix in the render method. I thought about something like:

  const activeBsPrefix = custom ? 'custom-control' : bsPrefix;
   <div
          style={style}
          className={classNames(
            className,
            activeBsPrefix,
            custom && `custom-${type}`,
            inline && `${activeBsPrefix}-inline`,
          )}
    >

Is there a better way to override bsPrefix ?
It does saves a bit of logic but if a user passes a custom bsPrefix it will override his prop and may cause unexpected behaviour.
WDYT?

[taion]

no, i was sort of speculating that a "neat" API would be to do something like bsPrefix="custom-control". but i think that's a little too cute.

i'm okay with this API

[eladlevy]

So... @jquense Do you think this PR can be merged?

[jquense]

Can you rebase?

[eladlevy]

Sure. I've rebased latest master on top of my branch so no dirty merge commits will appear.