[docs] Adds documentation to CoreObject for native classes

[pzuraq]

Adds documentation for native classes, prepping for making the officially public API.

[mike-north]

Is this supported/encouraged/discouraged?

export default class XFoo extends Ember.Component({

  // properties that I deliberately want to share between instances
  tagName: 'ul',

  fullName: computed('firstName', 'lastName', function() {
	return `${this.firstName} ${this.lastName}`;
  }),

  // immutable "defaults" for member data, deliberately shared across all instances
  firstName: '',  
  lastName: ''

}) {
 
  // standard ES6 class stuff

  logName() {
    console.log(this.fullName);
  }
}

[pzuraq]

Discouraged, since it will be very difficult to codemod half-way states like this. It's much easier for us to go from a clean-slate to full ES classes in the codemod. The purpose of the ability to do this is so addon authors can fully adopt early on, and so we have a path forward for mixins.

[pzuraq]

I don't think this should be addressed in here, but in a linting rule. We shouldn't even suggest this is a possibility in our docs, ideally. We could cover it in guides though.

[rwjblue]

@pzuraq - I'd like to get this back on track, think you might have time to revive it soon?

[mike-north]

The example above refers to CoreObject, and the above sentence would seem to suggest that I can use new Foo() as long as I extend from CoreObject instead of EmberObject. Is this accurate?

[pzuraq]

Good catch, that is not accurate. Will update to refer to CoreObject instead