ensure assumed constants are handled in a consistent manner

[szvsw]

• it's likely a bit inconsistent right now - some constants may exist in the epinterface.interface module (which contains all the EnergyPlus type-safe data entry components) as default field values in the various EP BaseObj classes, and some may exist in the sbem.components as either hardcoded or assumed_constant arguments passed in to construction of BaseObj during the sbem.Component's add_to call, while others may exist as default field values in the sbem.Component's class definition.
• We should choose a consistent approach, if possible
• One of the reasons we have inconsistency is that some values we do not want exposed in the sbem component schema, so they must be passed in directly to the epinterface.interface.BaseObj classes; while other assumed constants are for fields that we are exposing in the various epinterface.sbem.common.NamedObj but not expecting users to provide, and these field values are being passed in to the class definition as default field values. It's unclear to me why we are including these field values in the sbem components if they are not being sourced from the users, except for the motivation that some users may want to include them, but this would require exposing them in excel or other data entry methods.
• One potential solution is to isolate constants between the two domains - i.e. assumed defaults which are necessary for energy plus object instantiation but which are not part of the user-facing component schema, and assumed defaults which are part of the user facing schema.