Make a point class similar to "base", but without zero, span, or typical value

Most of the time, zero, span, and typical value are unused, cause confusion, and/or lead to easy but costly mistakes. Typical value is probably the most useless PI Point attribute. It doesn't affect the PI system. It is just there for the user's reference. Why not a range of typical values? Why not calculate it dynamically based on actual data? Typical value is superseded by limit traits in PI Asset Framework, so there is no need to force a typical value on every PI Point. Zero is mostly used for Float16 PI Points, which is probably rarely used these days. The concept of zero in cases other than Float16 is sufficiently covered by point types having a minimum possible value that they can store. Arguments similar to the ones against zero can also be used for span, but span has an additional reason to disappear. Exception and compression deviation (E&CD), whether they are specified in engineering units (EU) or as a % of the span, are saved as a % of the span. This means that any edit to the span results in a change in the E&CDs when they are interpreted in EUs, which is an unexpected surprise for the PI administrator if they are used to thinking of E&CD in terms of EUs. After all, EUs are the default way to specify E&CD in PI System Management Tools, so why would anyone think that this is not what gets saved to the PI Data Archive? In cases where the span is increased, this can cause the E&CDs to be larger than intended, resulting in data loss. The mistake is too easy to make (I made it twice already), and it is too tempting to correct the span from its default value when another PI administrator asks why the span does not reflect the corresponding tag in the data source. Many PI Points do not need a span. Just remove it. I realize that a point class without zero, span, or typical value would mean that the Float16 point type cannot be used and that E&CDs can only be specified and saved in terms of engineering units, but this "sacrifice" is actually very appropriate in a lot of cases.