Feature: support nullable Success value and generalise Failure type to Object

[lhengl]

This PR makes two key improvements to the Result<S, F> type, addressing issue #13:

1. ✅ Allow Nullable Value in Success<S?>

Previously, the Success constructor required a non-null value, even if T was nullable. This made it impossible to return a Result<S?, F> where the success case might legitimately carry a null (e.g., empty optional data, database fetch miss, etc).

Now:

• Success<S?> allows null as a valid success value.
• Keeps the API expressive and avoids awkward workarounds.

Why this matters:

• Encourages correct modeling of optional values within the result type.
• Eliminates the need for Option<Result<S, E>> or nullable wrappers around Result.

Result<String?, Error> result = Success(null); // ✅ Now valid

2. 🔁 Change Default Failure Type from Exception to Object

The original design constrained Failure to use Exception as the default failure type. While that aligns with standard error handling, it’s unnecessarily restrictive.

This PR changes the default to Object, allowing more flexibility, such as:

• Returning a simple String as an error message.
• Using enum-based or code-based error structures.
• Supporting non-Exception types without having to wrap or cast.

Result<String, String> result = Failure("Something went wrong"); // ✅ No need to throw or wrap

Why this matters:

• Makes the API more ergonomic and expressive for Dart developers.
• Enables functional-style error handling without forcing exception semantics.
• Encourages lighter-weight, clearer domain errors in application code.

🌟 Summary

These changes make result_dart more idiomatic, flexible, and aligned with how functional result types are used across languages like Kotlin, Swift, and TypeScript.

• ✅ Supports true S? success values.
• ✅ Removes restriction on failure types.
• 🧪 Fully backward compatible for users of Result<S, Exception> and non-nullable S.