Consider moving common rich text editing plugins into core

[JohnMcLear]

What's currently wrong?

Plugins are not optimized

• Too many HTTP requests
• Lack of front end tests
• Lack of i18n implementations
• Can't be enabled/disabled on a per pad basis
• Site admins don't know about them ergo users don't know about them.
• Making changes to plugin settings is a pain (requires modifying settings.json)

  Which plugins would I recommend putting as defaults?

Some plugins are pretty commonly installed, mostly Rich text ones such as.

• ep_align
• ep_headings
• ep_font_size
• ep_font_color
• ep_page_view
• ep_font_family

  Pros of introducing plugins to core

• Faster page loading
• We can maintain the code (for example @fourplusone has pretty much abandoned his work on headings
• We can probably remove some of the bugs that are caused because hooks don't exist
• Obvious to users they can have a rich text editing environment
• Buttons can be enabled/disabled in settings.json

  Cons of introducing plugins to core

• We have to maintain that code
• Bloats Etherpad a bit
• Means new developers might not feel comfortable adding RTF Stuff
• Our plugin framework is less well maintained and can end up with holes which having these plugins as plugins should solve.

  The ideal solution would be to solve #2350

With #2350 solved the plugins can stay as individual node modules and we can stlll help maintain and they get served minified.. That's the real win/win.. We can still package Etherpad up with some plugins in node_modules if we so chose, we should just deliver them under a disabled by default flag and allow the user to enable them by modifying settings.

@cweider was the original author of require-kernel and yajsml both of which I really struggle come to terms with working on. If anyone can chip in to help provide alternatives I will be more than greatful!

[JohnMcLear]

Decided against with the intention to minify plugins or some such.