feat: Allow fileInput props on rive view

[mfazekas]

Basically allows simplified code:

function Foo() {
  const {riveFile, error, isLoading} = useRiveFile(require('foo/bar/baz.riv'))
  
  
  return (<RiveView file={riveFile} ...>
   </RiveView>)
}

to be written as:

function Foo() {
  return (<RiveView file={require('foo/bar/baz.riv')} ...>
   </RiveView>)
}

Advantages:

• simpler examples
• migration to new lib is easier
  Disadvanteges:
• going from simple use to advanced is harder.

Alternatives:

• introduces RiveController, that's really just a file and dartboard/statemachine for now

[HayesGordon]

@mfazekas this is great, and I think it will be useful for people migrating. But there are (and will be) a lot of other breaking changes. We should aim to only add this (and other similar) if it enhances this runtime. We shouldn't let the old runtime usage drag us down.

With that in mind, I like the above. My only concern is that over time, we add more and more affordances to the RiveView that will hide the underlying intended usage.

There is a big advantage in people understanding that they own/manage the lifetime of the Rive File object - we've learned that lesson in our other runtimes. Creating view model instances is also reliant on having the file object. Having one way to do something will reduce the amount of if this then that docs we need to write.

People can always write their own wrappers to simplify this.

I still like this change, though. But my concern is that people will ask that we allow them to customize the loading and error state - and the answer there will then be an if this then that. So the options are:

• we expose a way to set the loading and error state (complicating the base usage that does not need it)
• we recommend managing the file resource yourself (which any serious Rive user should be doing anyway)