Type Converter Enhancements

[mthamil]

This pull request implements a series of changes intended to enhance and improve the use of type converters. It partially addresses #68, but does not include line or column numbers. It also fixes #66.

• ITypeConverter's conversion methods now take the PropertyInfo of the class property being converted to or from. This provides type converters with much needed context and metadata. For example, custom attributes could be applied to properties and then retrieved during conversion. Unfortunately, this is a major breaking api change. I am open to suggestions about ways to ease or avoid this. An entirely new interface could be added, but I did not pursue that. #68 specifies "Destination Object Type (not the property)", but PropertyInfo provides access to this information and more.

• When writing files, ITypeConverter.ConvertToString was not being used at all, relying simply on ToString(). LineBuilderBase has been modified to use a type converter if provided.

• Finally, two additional methods were added to IFieldSettingsConstructor: WithConversionFromString and WithConversionToString. These both take lambda functions, one converting to a property's target value from a string when reading, and the other converting from a property's value to a string when writing. These are simpler to use than implementing a fully-fledged type converter, but the existing type conversion machinery is still used underneath. I tried to get the inferred property type to flow from the WithMember call, but after several aborted attempts, I gave up. The interaction of inherited interfaces and generic type arguments is fairly complex, and I could not find a way to make it work.

[igitur]

@forcewake Any chance to look at this PR soon? I would certainly benefit from this.

[mthamil]

@igitur I don't know if this helps you or not, but I've been working on a hard fork of this project at https://github.com/mthamil/FluentFiles with several enhancements, including this one. I just released v1.0.0.

[igitur]

@mthamil Thanks. Forks... this is both the pro and con of open-source development. As someone who's maintaining a few open-source projects myself, I would prefer to keep development on the original fork, where possible.

@forcewake What's the story? If you're overwhelmed with maintaining this project, clearly people are here to help? I can also contribute, e.g. setting up a CI pipeline and help with releases. Please add your opinion on where this (awesome) project is going.