gst/format: some more improvements and fixes

Please note that the 3d commit calls for discussion.

1. Cleanup format related re-exports in gst/lib.rs and reduce the impact on the prelude. I used to stuff every single trait there even those which were internally resolved. See the resulting changes in lib.rs. Besides the prelude, I decided not to re-export the traits under the main gst module because they are rarely used. APIs need to refer to e.g. gst::format::FormattedValue instead of gst::FormattedValue, or just use gst::format::FormattedValue; to get FormattedValue.
2. The GST_FORMAT_PERCENT_SCALE constant was not used to compute the value to display. I took this opportunity to add examples showing how to format Percent display.
3. I noticed the specific formatted values still exposed their inner value as pub. This is convenient in practice, but users are easily able to build, say a Default(u64::MAX), which when passed to C would be considered as the None variant of this format. This is something that has been removed from ClockTime for quite some times. Users can build values using the constructors such as from_seconds or using operations such as 10 * gst::ClockTime::SECOND. Getting the value as plain integer is just one deref away (e.g. *duration). So in this 3d commit, I proceeded to remove the pub specifier from the remaining specific formatted values and added constants to help building those. Users can write 10 * Buffers::ONE or 512 * Bytes::K for instance. I added examples to help users discover what can be used to build values. Impact on existing code in gstreamer-rs and gst-plugins-rs is OK IMO. But then I realized that this doesn't actually solve the problem: users can still call u64::MAX * Buffers::ONE which from a C perspective is None. Of course, I don't think checking the result of each operation would be a good move performance-wise. I guess the only obvious workaround for this would be to check the value before calling in a C API (e.g. in FormattedValue::into_raw_value & IntoGlib implementations). But then, would it be worth removing the pub specifier? We can still keep the new constants anyway.